Do you close PBIs, tasks and goals with context?

Last updated by Brady Stroud [SSW] about 1 month ago.See history

PBIs, tasks, and goals are the backbone of work regardless of whether they are stored in Azure DevOps, GitHub, Jira, Trello, or some other platform. When you finish a task, marking it as done is satisfying, but remember to add a closing comment for future context. By adding a closing comment, it allows others to understand why the PBI was closed and what the outcome was. This comment is critical when closing a PBI as "Won't Fix" or "Duplicate" but is valuable in all scenarios and should be the default approach. For example, if you have UI changes, a couple of screenshots can go a long way to help the team understand what was done. Similarly, if there are changes to architecture documents or the readme, providing a link to those artifacts helps others get across the change.

When you look at a PBI, you can navigate through the commits or pull requests that were linked to the PBI. This is great for understanding the code changes, but that doesn't easily show you what the outcome was.

closing pbis without context
Figure: Bad example - This PBI is closed with no context around changes made

closing pbis with context
Figure: Good example - This PBI informs the team that the work is complete and contains some examples of what the changes look like

Screenshots are just one of the things that you could add for more context, some other things you could add are:

  • Done Videos
  • Mention if there is relevant documentation that was updated
  • Mention any additional context in the pull request that you didn't want to duplicate
  • If you'd had a conversation with someone to change the outcome of the PBI, mention "as per my conversation with..."
  • If you are closing a PBI as "Won't Fix" or "Duplicate", mention the PBI that you are closing it as a duplicate of or why you won't fix it

Note: If you are using GitHub projects you will want to make sure you've checked the workflows for the your project to make sure the team understands the behavior of the work when it's state changes in the project.

You can open the Hamburger menu | Workflows to view all the workflows

project workflows
Figure: For issues specifically it's recommended you have these workflows configured and enabled

We open source. Powered by GitHub