Do you close PBIs, tasks and goals with context?
Last updated by Brady Stroud [SSW] about 2 months ago.See historyPBIs, 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.
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