SSW Foursquare

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

Learn more on Rules to Better Scrum.

  1. Do you use the Scrum template with Azure DevOps?

    When initiating a new project in Azure DevOps, selecting the right template is crucial as it sets the groundwork for project management and collaboration. The Scrum template is a recommended choice due to its adherence to widely recognized Scrum terminology and practices. This rule guides you on how to select the Scrum template and elaborates on the benefits of doing so.

    1. Go to Azure DevOps | New Project.
    2. Fill in the Name, Description, Visibility.
    3. Click Work item process | Scrum.
    4. Click Create.

    create new project
    Figure: Create a new project

    select scrum template
    Figure: Select the Scrum template

    Using the Scrum template has its fair share of cool perks:

    Terminology: The work item types and states are all in Scrum-speak, which helps everyone on the team get on the same page quickly.

    Consistency: It keeps things uniform across projects, so jumping in and out or teaming up is a breeze.

    Azure DevOps does have other templates like Agile and CMMI, but the Scrum template has a special spot. It sticks to the Scrum playbook, making it a go-to for teams keen on keeping the Scrum spirit alive. It's all about boosting agility, making chats flow easily, and letting new folks blend in without a hitch.

    scrum template backlog
    Figure: Product backlog has Product Backlog Items (PBIs)

    scrum template states
    Figure: PBI states are terms which are Scrum terms

  2. Backlog - Do you know how to create a Sprint Backlog?

    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.

  3. Tasks - Do you know when to check in code and associate it to a task?

    In Scrum you work only on tasks in a Sprint, and the task must belong to a committed PBI. As such, when you commit 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

  4. Tasks - Do you know to ensure that relevant emails are attached to tasks?

    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 parties 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.

  5. Reports - Do you know which reports are the most important ones to track your progress?

    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?

  6. Do you turn an email into a PBI before starting work?

    Emails are a natural way for people to give feedback about a product. Unfortunately, they also serve as a poor mechanism for performing work. As work is done, the thread can become untenable by splitting off into multiple different threads and becoming buried among other emails.

    That's why when a feedback email is received, it is important to turn it into a Product Backlog Item (PBI) and communicate that back to the sender.

    If someone often sends email tasks rather than creating PBIs, kindly suggest they create PBIs directly to save time and keep workflows organized.

    Benefits of turning emails into PBIs

    There are several benefits of turning an email into a PBI including:

    Providing one source of truth

    Better prioritization

    Easily accessible by anyone in the team

    Should the email become a PBI?

    Of course, you should use your judgement to decide if the email needs to become a PBI. For example:

    • Does the email contain 1 or more actionable tasks? If not, do not turn into an PBI.
    • Does the feedback contain confidential information that should not be on the backlog? If so, do not turn into an PBI.
    • Will the task take less than 15 minutes to complete? If so, follow the "touch it once" principle and do it immediately.
    • Is the emails marked urgent? Urgent emails should be done immediately unless they are clearly not an emergency.

    Use the following flow chart to determine if an urgent email should be turned into an email.

    Figure: Should the email be turned into a PBI?

    New PBI - Steps to turn an email into a PBI

    It's important that you follow the right steps so that the PBI contains all the information someone would need to find the original email thread, and also so that the original sender knows where the PBI is, and whether it has completed.

    1. Create a PBI in the backlog and give it a name
    2. Copy the email header into the top of the PBI, indent it and add the words "Based on email chain:" so that the email can be found later.
    3. If possible, replace the users with @mentions, if you'd like to keep those users informed.
    4. Fill out the Description
    5. Ensure that the Product Owner is @mentioned in the PBI
    6. Add an Acceptance Criteria: "Reply 'Done' to all emails mentioned in this PBI and @mention the sender with 'Done'"
    7. Prioritize the PBI. If it is important, then it should be added at the top of the Product Backlog after the current Sprint items. Otherwise, you should make your best guess as to its priority.
    8. Reply back to the original email saying: "That's awesome feedback, we have a PBI for prioritization: {{ URL }}
      For future issues, if you have access, please add your comments to items in that backlog 🙂"

    Based on email chain:

    From: Bob Northwind "[email protected]"
    Sent: Thursday, 24 November 2023
    To: Jane Doe "[email protected]"
    Cc: John Davis "[email protected]"; Eliza Northwind "[email protected]"
    Subject: TimePro PBI 50209: ☠️ Displaying past employees

    Figure: OK example - Has the email header data but not @mentioning users

    Based on email chain:

    From: @BobNorthwind
    Sent: Thursday, 24 November 2023
    To: @JaneDoe
    Cc: @JohnDavis @ElizaNorthwind
    Subject: TimePro PBI 50209: ☠️ Displaying past employees

    Figure: Good example - Has the email header data and @mentions users

    Tip: If the request from the client is too large for one PBI, then it will need to be turned into multiple PBIs 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 PBI

    Existing PBI - Steps to update a PBI according to an email comment

    Sometimes you will receive feedback on an existing PBI within an email. It is important to inform the sender and keep them up to date.

    1. Copy the email header into to a comment within the PBI, indent it and add the words "Based on email chain:"
    2. If possible, replace the users with @mentions, if you'd like to keep those users informed.
    3. Add an Acceptance Criteria: "Reply 'Done' to all emails mentioned in this PBI and @mention the sender with 'Done'"

    Keeping the PBI up-to-date

    If there is more communication in emails at a later date, it's important to make sure the PBI stays in sync with the emails. Otherwise, the source of truth will become confusing since there will be differing information in 2 places.

    When there is a new update in emails do the following ASAP:

    1. Update the PBI with any relevant information
    2. Mention that it was updated as per the email thread in the discussion

    email example
    Figure: Bad example - Don't work from your email inbox!

    pbi example
    Figure: Good example - Put it in a PBI!

    Turn emails into Tickets

    If you use a ticketing system like Zendesk, you should follow a similar process to the above to turn emails with tasks into tickets.

    1. Reply All to the email, add "(zendesking)" to the top and remind the sender that the email should have been sent to Zendesk instead, e.g. "Please remember to send tasks to our Zendesk address in the future :)"
    2. CC your Zendesk email address on the reply - no need to copy the header info, since this will already be included
    3. When the task is done (or if there are other updates), reply in Zendesk - the email will go to everyone originally included in the email.

    Figure: Good example - send it to Zendesk!

  7. Do you estimate all tasks at the start of the Sprint?

    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 1710232021934
    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.

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

    A PBI (Product Backlog Item) is a term commonly used in Agile project management and software development to represent a unit of work. It refers to an item in the Product Backlog, which is a prioritized list of features, enhancements, or fixes to be addressed in a project.

    Before a PBI is worked on it should be added to the current Sprint Backlog during Sprint Planning. If your PBI doesn't exist, or is in an email then you need to turn it into a PBI to be prioritized in Sprint Planning.

    Once a PBI is in the Sprint Backlog, it's lifecycle can be broken down into 3 steps:

    1. Ready

    You have a Sprint Backlog of PBIs (tasks, features, and fixes) which are already prioritized and approved by the Product Owner

    1. Choose a PBI
    2. Double check the Definition of Ready
    3. Break the PBI into tasks (optional)

    Testing task
    Figure: "Testing Task" added to a PBI. This is the board the team will use for 90% of the Sprint so that testing is visible to everyone

    2. Time to Code

    This step depends on the complexity and nature of the task, especially if the PBI involves intricate coding or extensive testing to meet the defined Acceptance Criteria.

    1. Move PBI to "In Progress"
    2. Create a branch
    3. Code, code, code... (make sure to Red-Green-Refactor)
    4. Make a Pull Request with lots of context
    5. Get an "over the shoulder" review
    6. Record a Done Video so you get your ducks in a row for the explanation to the Product Owner
    7. Show the Product Owner so they give you earlier feedback
    8. Action the feedback (and then get more feedback)
    9. Check your Definition of Done and complete the Pull Request!

    3. Done

    This should be the easiest part!

    1. Check code is deployed 🚀
    2. Reply 'done' to the PBI and also in the email thread, as per when to send a 'done' email in Scrum

      Note: Remember to close PBIs, tasks and goals with context?

    3. Close the PBI

    Congrats, your PBI is ready to be demonstrated during your Sprint Review!

    3 steps to a pbi V7 2
    Figure: The important steps in a PBI lifecycle.

    Print out the SSW 3 Steps to a PBI PDF and put it on your "War Room" wall.

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

    Bugs are often hard enough to resolve but when they don't detail how to reproduce the bug, or what the expected behaviour is, it wastes a lot of time and gets frustrating for the developers. Detail in a bug report is key to your teams effectiveness and success. This is not limited to bug reports, for example PBIs can be missing Acceptance Criteria.

    In Azure DevOps, a great way to ensure you capture all the information required is through templates for your work items. Templates allow you to guide users through all the required info in a clear and concise manner, ensuring you will always have clean and detailed steps to reproduce a bug.

    templates for pbis and bugs   bad example
    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
    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 customize the template for a work item type
      templates for pbis and bugs   customise
      Figure: Customizing a bug work item
    2. 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)
    3. Save Template

    Sample code template

    <!-- These comments automatically delete -->
    <!-- **Tip:** Delete parts that are not relevant -->
    <!-- Next to Cc:, @ mention users who should be in the loop -->
    
    Cc:
    
    <!-- add intended user next to **Hi** -->
    
    Hi
    
    ### Describe the Bug
    
    <!-- A clear and concise description of what the bug is. -->
    
    ### To Reproduce
    
    Steps to reproduce the behavior:
    
    1. Go to '...'
    2. Click on '....'
    3. Scroll down to '....'
    4. See error
    
    ### Expected Behavior
    
    <!-- A clear and concise description of what you expected to happen. -->
    
    ### Tasks
    
    - [ ] Investigate
    - [ ] Fix
    
    ### More Information
    
    <!-- Add any other context about the problem here. -->
    
    ### Environment
    
    - Device: [e.g. iPhone 12]
    - Browser: [e.g. chrome, safari]
    - OS: [e.g. iOS]
    
    ### Screenshots
    
    <!-- If applicable, add screenshots to help explain your problem. -->
    
    Thanks!
  10. Bugs - Do you know how to handle Bugs on the Product Backlog?

    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.

    Examples:

    • 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

  11. Do you have a product roadmap?

    A Product Backlog is a great way to see the fairly small broken up Product Backlog Items (PBIs) that make up your team's "to do" list, but it can be a bit too zoomed in and makes it easy to stray from the Product Goal.

    To get a better zoomed out view, you should have a product roadmap.

    Video: Do you have a product roadmap?

    You can think of it as a list of milestones to reach a goal.

    Here's a simple example about going on a trip to Beijing

    1. ✅ Visit the Great Wall of China
    2. ✅ Visit the Forbidden City
    3. ⬜ Visit the Summer Palace
    4. ⬜ Visit a popular street food area
    5. ⬜ Leave for Sydney on 25th of September

    Here you can see that the goal was to visit various attractions in Beijing and each attraction is a milestone to be reached before returning home to Sydney.

    For software development, you simply replace the milestones with ✨features, 🐛fixes, etc.

    Having this zoomed out view helps the team to stay focused on the overall goal of the project and the long term priorities. It also prevents the team from getting side-tracked on issues that are not really what the business wants.

    Building the product roadmap

    It's important to think about the scope of the product when building the product roadmap so that the milestones are an achievable grouping of tasks. Consider the size of your team:

    • For small teams that shift to different products a lot, you might want to make the milestones a bit more granular and short term.
    • For larger product oriented teams, it is more important to have a general overview of what is going to happen across a longer timeframe.

    By factoring in the size of the team, it keeps everyone accountable while remaining realistic.

    Ways to track a roadmap

    There are heaps of tools out there you can use to make a product roadmap including:

    These tools have a lot of functionality and use differing complicated terminology like Features, Epics or MMFs (Minimum Marketable Features). So, they can be an intimidating first step into product roadmaps.

    At their core, product roadmaps are simply a list of critical milestones to tick off as they are completed. So, as a stepping stone, you can store them in your project wiki.

    The project wiki makes the concept much easier to understand and implement. Once the team is comfortable with the idea, move on to more complex tools.

    Ideally, you want to make some progress on product roadmap items in every Sprint, so make sure to review your product roadmap during your regular Sprint Reviews.

    sophiebotroadmap
    Figure: Good example - A small team might have something like the SophieBot product roadmap

    See: SophieBot product roadmap

    microsoft365roadmap
    Figure: Good example - A large team might have something like the Microsoft365 product roadmap

    See: Microsoft365 product roadmap

    githubroadmap
    Figure: Good example - GitHub maintains their product roadmap using GitHub Projects and GitHub Issues

    See: GitHub product roadmap

  12. Do you get the work items into Azure DevOps via Excel?

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

    • Open SSW Priorities Estimate Template in Excel
      ExcelSSWTemplate
      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

      ExcelFindProject
      Figure: Find your project in the list

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

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

      ExcelChooseColumnsButton
      Figure: Click 'Choose columns'

      ExcelChooseColumnsList
      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
  13. Do you link related and duplicated Work Items?

    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

  14. Do you know how to create your Project Portal (for existing Azure DevOps Team Projects)?

    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. Do you know how to handle Undone Work (aka V2 for PBIs)?

    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".

    e.g.

    • 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 attainable 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. Backlog - Does your Product Owner know how to maintain the backlog?

    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.

    Typing
    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

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

    GitHubIssues
    Figure: Good example - Github Issues

    3. Azure DevOps - E.g. https://ssw.visualstudio.com

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

    What's next?

  17. Do you use a Police Line in your backlog to help focus you on your MVP (Minimum Viable Product)?

    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. Do you send a PBI via email to raise visibility?

    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’

  19. Do you escalate key updates and deliverables?

    Key updates on projects may include Done Videos, critical text additions, or specification documents. Typically, links to these deliverables would be added to the PBI that they relate to and the relevant people would be mentioned.

    critical update bad example
    Figure: Bad example - Automated notifications from project management tools can be easily missed or overlooked amidst other notifications

    critical update good example
    Figure: Good example - For visibility and to ensure all stakeholders are in the loop, you should also send an email to the relevant people

    Not every PBI will require an email, but if it is a key update or deliverable, it should be escalated. The developers would make this judgement call, although this could also be added upfront by the Product Owner in the Acceptance Criteria for the PBI. Here are the 3 scenarios:

    1. Standard PBI - needed but the outcome is not very interesting: Do the PBI, just following the DoD
    2. Interesting to someone - @ mention them
    3. Really important - Make sure it’s top of mind, email it

    For example, you can send an email similar to this to share a new Done Video to the relevant stakeholders. If you working on a big system or internal projects, include the feature area or project name in the subject for additional context.

    This email is especially important for stakeholders that don't use, want to use, or have access to the project management tools. If they do have access, remember to also @mention them in the PBI update.

    Sometimes the PBI work originated from an email, in which case you should reply to the email instead of starting a new email. This will allow stakeholders to have additional context.

    Additionally, giving the the Product Owner and/or Stakeholder(s) a call to show them the video is great - this ensures they watch it and you can get instant feedback.

    Notes:

    • Major bugs found on the product should also be communicated to the PO as soon as they are found, e.g. unable to create an invoice
    • You should be able to easily tell if a PBI was created from email. As per turn an email into a PBI before starting work
We open source. Powered by GitHub