Secret ingredients to quality software

SSW Foursquare

Rules to Better Scrum using Azure DevOps (Work Items) - 18 Rules

Learn more on Rules to Better Scrum.

  1. Prior to your meeting with the customer you should prepare. Get your Sprint Planning (was Release Plan') email ready, so after the meeting you can adjust and promptly send it.

    Learn how to create your Sprint backlog:

    Once the backlog is ready, you should send the Sprint Forecast email to the client.

  2. In Scrum you work only on tasks in a Sprint, and the task must belong to a committed PBI. As such, when you check-in code in Azure DevOps (was TFS), you should associate it with the task you are working on rather than the PBI.

    The reason behind this is that doing so provides a better way to track change sets in a Sprint and give full traceability for work done during the Sprint.

    Change set 123 was associated to PBI 'As an end user I want to be able to lookup customers'

    Bad Example - The change set was associated to a User Story not a Task

    Change Set 123 was associated to Task 'Create database fields for customer' which is part of PBI 'As an end user I want to be able to lookup customers

    Good Example - The change set was associated to a Task

  3. Often you will receive rich information from your Product Owner (customer) about tasks. That information can be in the form of Word documents, but you generally receive them in the context of an email. This should be done by one person called the scribe.

    The scribe will:

    1. Take screenshots and notes
    2. Turn them into multiple emails
    3. Add them into Azure DevOps (Note: You can't do this in GitHub)

    You need to keep these so your team can refer to it later, and so you can send a “Done” when the task has been completed. This preserves the history of the task and allows you to keep relevant partied included in any future conversation.

    Keep the original email so that you can reply "Done" and delete the email.

    More information

    You should follow the existing Rules to Successful Projects and attach the email to your task so you can refer to and reply to it later when you close the task:

    Following these simple rules will help your Product Owner understand you better, and allow your team to more effectively collaborate with each other.

    An added bonus is that as we are keeping the email history in sync with Azure DevOps. When you “reply all” to the email all of the interested parties to the Task are also included. This notifies those that may have been blocked by your task to keep up to date with its status.

  4. In Scrum there is only one report that the team needs to track their progress.

    burndown good example
    Figure: The burndown has all of the information you need to know if you are going to hit your mark

    There are however other reports that matter for management and putting together the bigger picture.

    See Do you get regular updates on costs and progress?

  5. If a product owner sends an email to the development team with a request, that email should be turned into an Azure DevOps Work Item before any work is started or the work is prioritized on the backlog.

    If the email's contents or subject do not need changing, then no response email is required. This would create another unnecessary email in the world.

    However, if the subject is unclear, send a response as per the rules Do you know when you should change a subject? and Do you realize the importance of a good email Subject?

    If the request from the client is too large for one Work Item, then it will need to be turned into multiple Work Items as per the rule Do you keep your PBIs smaller than 2 days' effort? In this case, you will need to let the client know this and include URLs to each Work Item.

    Note: Once you've moved the email into Azure DevOps as a work item, you should delete the original email from your inbox or move it to an Outlook folder called "Moved to Azure DevOps" to avoid duplication.

    2014 11 10 13 17 43 compressor
    Figure: Now the new Product Backlog Item is in the Product Backlog

  6. In Scrum it's important to flesh out the details of a PBI when it makes sense to do so.

    You should estimate your PBIs as soon as you can, but you don't need to break all of your PBIs down into fully-estimated tasks as soon as they're added to the backlog.

    However, before starting work on a Sprint, you should always break the PBIs in that Sprint into estimated tasks.

    Azure DevOps can use the remaining hours assigned to tasks to calculate the burndown. By breaking the PBIs down into tasks with estimates, your burndown will start looking correct right from the first day of the Sprint.

    burndown bad example
    Figure: Bad Example - The tasks weren't estimated at the start of the Sprint

    burndown good example
    Figure: Good Example - The tasks were estimated from day one

    Note: If you're not using task estimates, you can configure Azure DevOps to create a Sprint Burndown using PBI Effort instead.

  7. Do you know the 3 steps to completing a PBI?

    The lifecycle of a PBI can be broken down into 3 steps:

    1. Ready

    1. Take the next PBI that was approved by the Product Owner
    2. Is the PBI ready? Check your PBI against your Definition of Ready. "Ready" PBIs must have Acceptance Criteria. A good Definition of Ready also encourages a test-first mentality in requirements e.g. Use Spec Flow (Given, When, Then) and/or create Test Cases and Test Steps first.
    3. Attach and copy the Product Owner's email into the Acceptance Criteria (as per Do you attach and copy emails to the PBI?).
    4. Email notification to the Product Owner - use the @ mention rule
    5. Break down your PBI into tasks.
    6. Don't forget to make a task for testing! (So that it is visible in the task board). Note: You can also customize the kanban board by adding a new column for testing, but we recommend adding a testing task to the PBI instead.

    KB customize board columns
    Figure: Adding a new "Test" state. This is only visible in the Product Backlog and not the Sprint Backlog

    Testing task
    Figure: Testing Task added to PBI. This is the board the team will use for 90% of the Sprint, so testing should be clearly visible here

    2. Code

    1. From the PBI, create a new branch (so that your work is automatically tagged to the PBI)
    2. On the Kanban Board, move your Task into "In Progress"
    3. Checkout your new branch and start coding!
    4. Code, code, code… (Red, Green, Refactor)
    5. Push your changes, open a Pull Request
    6. If you want feedback early, record a Done Video. E.g. Snagit

    3. Done

    Is the PBI "Done"? Check your Definition of Done, and then:

    1. Open a Pull Request
    2. Get another engineer in your team to do an "over the shoulder" check of the code
    3. Use Microsoft's "Test and Feedback" Chrome extension to test the app
    4. Make changes based on feedback (and then get more feedback)
    5. Complete the Pull Request! Merge changes to master, this automatically deploys (to either Test, Staging or Prod based on process maturity)
    6. Email notification to the Product Owner – send a Done Email (reply to the original). Big items should have a Done Video
    7. Check the Acceptance Criteria for notes about email attachments (as per Do you attach emails to the PBI?).

    Congrats. Your PBI is now ready to be demonstrated during your Sprint Review! (Note: This is also the same process you follow for a Bug work item)

    Good Figure: This image includes all the important steps in a PBI lifecycle. Print this "SSW 3 Steps to a PBI pdf" and put it on your 'War Room' wall

  8. Do you have templates for your PBIs and Bugs?

    Often bugs are hard to reproduce because they are inconsistently described, and people forget to say what they expected to see. To increase consistency of bug reporting - it's a great idea to add templates for work items in Azure DevOps. It guides people into the pit of success as it helps them fill in all the required info in a clear and concise manner – then you will never see unclear steps to repro a bug again.

    Often bugs are hard to reproduce because they are inconsistently described, and people forget to say what they expected to see. To increase consistency of bug reporting - it’s a great idea to add templates for work items in Azure DevOps. It guides people into the pit of success as it helps them fill in all the required info in a clear and concise manner – then you will never see unclear steps to repro a bug again.

    templates for pbis and bugs   bad example

    Figure: Bad Example – This new bug template doesn’t make it obvious how the team likes their steps to repro

    templates for pbis and bugs   good example

    Figure: Good Example – This new bug template guides the user to fill in the steps to repro in an ordered list and even prompts them to fill in what they expected to happen (and what actually happened)

    Setting this up is pretty easy.

    1. First you need to customise the template for a work item type templates for pbis and bugs   customise Figure: Customising a bug work item
    2. Choose the form control to edit

      templates for pbis and bugs - customise form.png

    Figure: Customising a bug work item form

    1. Choose the form control to edit templates for pbis and bugs   customise default value Figure: Set the default value for the Repro Steps field (tip: use HTML)
    2. Save Template

    Sample Template:

    <ol><li>First I did this</li><li>Then I did this</li></ol><div><b>Expected Result</b></div><div>I expected it to save properly</div><div><b><br></b></div><div><b>Actual Result</b></div><div>I got an exception (tip: you can copy/paste screenshots)

  9. Bugs that are introduced and found because of the current work in the Sprint are included in the Sprint and estimated immediately so the burndown remains accurate. All other bugs found independent of the work on the current sprint are placed on the Product Backlog.

    See Do you know when to create bugs? for detailed information on identifying when something is a bug, and when to just fix it.

    Using the Agile process template

    In the Agile template, you can't assign Story Points to bugs, meaning that they will negatively impact on sprint velocity.

    Bugs found that are independent of the work on the current Sprint are placed on the Product Backlog as a work item “Bug”. The product Owner then ranks the Bugs with priority amongst the User Stories. Bugs cannot have Story Points allocated to them so User Stories need to be created with Bugs as Child Work Items. This is only done when the PO has prioritized the Bug and the Bug is likely to make the next Sprint. At the Planning Meeting, the PO elects which Bugs are to be included and new User Stories are created to group them appropriately with due regard to Severity and Stack Rank. Once the User Stories have been created, The Team estimates the Story Points for each one; the Product confirms User Stack Rank and the Sprint Backlog is planned as normal.

    This process:

    • Works around the problem of Bugs not having Story Points
    • Allows Bugs of the same rank to be sensibly grouped together
    • Prevents arbitrary groupings of Bugs which cannot be properly ranked
    • Follows the estimate just-in-time philosophy of Scrum
    • Prevents small Bugs taking up a whole Story Point

    Using the Scrum process template

    In the Visual Studio Scrum template, bugs are just another PBI and you can assign a business priority and an effort estimate in Story Points. Bugs that make the cut for the next sprint can be broken down into tasks and estimated as required.

    As bugs from previous sprints are just PBI’s, the PO agrees to a list of bugs that will be fixed in the current Sprint.

    The team just fixes any new bugs they introduced in the current sprint.

    If the team finds bugs due to functionality accepted in a previous sprint they log it as a PBI and will complete the fix in a future sprint, unless it is a critical bug, in which case they raise it as an impediment to the current sprint to the PO.


    • Small bug – Text on a label is spelled incorrectly
    • Big bug - There is an error thrown when transitioning from page 1 to page 2 when you hold down the Ctrl key

    2016 02 08 12 02 29
    Figure: Bugs can be added "out of sprint" directly into the product backlog in Azure DevOps (was TFS)

    The Visual Studio team provides good guidance on managing bugs in VSTS

  10. Do you have a Product Roadmap?

    A product backlog is a great way to see the fairly small broken up PBIs (Product Backlog Items) that make up your team's to do list but it can be a bit too zoomed in.

    To get a better zoomed out look, you should have a product roadmap. This could be using Azure DevOps Features or Epics, sometimes also known as MMFs (Minimum Marketable Features), but the concept is the same...

    What is the priority order of the main feature groups that you will be working on? Features Figure: Azure DevOps PBIs organized by Features to see a long term Product Roadmap and high level priorities

  11. Initializing the Project - See how to get the work items into Azure DevOps via Excel:

    • Open SSW Priorities Estimate Template in Excel
      Figure: Find SSW Template - 'New | My templates... | SSW_Proposal-Project | SSWPrioritiesEstimateTemplate.xltx''
    • Add the tasks and additional tasks into ReleaseXX sheet ![Figure: Copy work items to ReleaseXX sheet](ExcelReleaseSheet.jpeg)

    Note: The Project Management tasks will be calculated based on your tasks

    • Create a new sheet and go to Team tab
    • Click "New List" and choose your project

      Figure: Find your project in the list

      Figure: Choose 'Input list' to download the empty template

    • Add the other useful columns e.g. Baseline Work, Remaining Work, Completed Work into Excel

      Figure: Click 'Choose columns'

      Figure: Select columns in the left list

    • Copy work items (including the Project Management tasks) from ReleaseXX to the new sheet ![Figure: Copy work items from ReleaseXX](ExcelWorkItems.jpeg)
    • Click "Publish" button to upload the work items to TFS
  12. If a work item is related to another Work Item or is a duplicate request, create a link between them on Azure DevOps.

    related work item 1
    Figure: Adding a related Work Item

    related work item 2
    Figure: Adding details about the related Work Item

  13. When a prospect/client is ready to move forward (typically after a Specification Review)...

    1. Create a TFS project (to track the work items and releases)
    2. Create a SharePoint project site

      You can do both of these at the same time by creating a Azure DevOps project and use a SharePoint dashboard.

      Figure: Choose to create a new SharePoint site when creating Azure DevOps project

    Note: It is also possible to create a new SharePoint site afterwards and attach it to a Azure DevOps project, via this hack

    1. Move all the documents you've created for this client, from the 'Prospects Site (Document Library)' into the new project site.

    A few other things to do frequently do right away:

    • If required, create an external user account for the Product Owner. This enables the client access to your SharePoint Extranet to see the documents, sites and reports.
    • If required, let the client know they can upload additional files, or download a copy of the project for testing and deployment.
    • Check permissions and access rights
    • Consider synchronizing the project documents offline via Outlook or SharePoint Workspaces
    • Edit the SharePoint site landing wiki-page and upload some pictures of the team
      Figure: Once your 'TFS Portal' is ready, add a picture of the team site, prior to letting them know about the new site
  14. Unfortunately the Azure DevOps team did not have time to build the feature to create a SharePoint site, after the project is created. Next version, we hope.

    There is a goofy work around:

    1. Create a new temporary project (with a SharePoint site for it)
    2. Disable the site for the new project, by checking off '[x] Enable team project portal'
    3. Go back to the old Azure DevOps project
    4. Enable the site for the original one (pointing to that newly created site)
    5. Finally, delete the temporary project you created

    More info at Configure or add a project portal

  15. The goal is always to complete Product Backlog Items (PBIs) for the Sprint Review.

    Often PBIs grow or change and it does not make sense to deliver what was originally proposed in the Acceptance Criteria.

    So think of a way to deliver business value and get it in production, then have a hallway conversation with the Product Owner to see if he agrees with you.

    Assuming approval, then adjust some of the Acceptance Criteria, add "v1" to the PBI name and move some of the functionality to a new PBI with the same title and "v2".


    • Customer and Contact Form v1
    • Customer and Contact Form v2

    Note: A common example for when to use this is when the full acceptance criteria of a large PBI (or Epic) would not be attaionable within one sprint, so splitting an Epic into 2 attainable PBIs is a better option.

    2021 07 30 14 58 22
    Figure: A v2 PBI in GitHub

    2021 07 30 14 59 25
    Figure: A v2 PBI in Azure DevOps

  16. All good Scrum teams have a backlog. The backlog is built by taking a conversation and recording it as one or more Product Backlog Items (PBIs) (e.g. Azure DevOps) or Issues (e.g. GitHub, JIRA).

    You should create PBIs during or straight after the conversation, rather than using emails that may never be entered into the backlog.

    Figure: Get typing during a conversation to make the meeting tangible

    The Product Owner is responsible for owning the Product Backlog. See the video on "Do you know how to be a good Product Owner?"

    Although these requirements come from the Product Owner, it is often the developers who will record these PBIs.

    1. Emails

    Bad Example - This is a poor way to add a PBI/Issue as you can’t order emails by the business priority

    Figure: Good Example - Github Issues

    3. Azure DevOps - E.g.

    Figure: Good Example - Azure DevOps allows you to enter an item into the backlog, in any priority order

    What's next?

  17. A Minimum Viable Product (MVP) is the core of your application that you should be aiming to build before you spend time on nice-to-haves, bells-and-whistles, and stretch-goals.

    To help focus your Product Owner and team on the core Product Backlog Items (PBIs) needed to fulfil the MVP, it can help to add a Police Line to your backlog.

    1. Create a PBI and call it either:

      1. -----------------------------------MVP----------------------------------
      2. -------------------------------Police Line------------------------------
      3. ---------------------------------Phase 1--------------------------------

    Then when deciding if a feature is vital or not, simply drag it above or below this line.

    backlog police line
    Figure: Good example – Police Line added to help the team prioritize

  18. With automatically sent backlog emails (Azure DevOps or GitHub), there is a risk of people deleting them without reading the content – it doesn't happen with manual emails that have unique subjects and a real person as the sender.

    If you have an important PBI and want to improve its visibility, then duplicate the content of the PBI into an email.

    Figure: PBI details copied to an email for better visibility, and also the email can get replied to with a ‘done’

We open source. Powered by GitHub