Pointing unplanned and unpredictable support issues
Hello,
I am a scrum master in a team of 5 developers. For the last few years, we would point only issues that reflected business value, i.e. stories, and not bugs that were generated as a result of customer complaints.
Recently, there has been a push from one developer to also point unpredictable and unplanned work, so as scrum master I'm wondering which way to go.
To be clear, i care about accurately planning how much work we can commit to each sprint much more than justifying where the time went.
Arguments for pointing bugs
- Bugs also take time and it would be nice to show where the team's time went.
Arguments for not pointing bugs
- Points represent effort, not time.
- If we point unpredictable work and let that increase the percieved team velocity and commit to work based on that, we will be over capacity the next sprint when more unplanned work comes up.
- If we point a bug before we fix it, we're very likely to be wrong due to unknowns.
- If we point a bug after it's done based on how long it took, then it will greatly be impacted by how slow/fast devs are (we have dev that has done 4x the number of story points than another on the team).
- We could get around the above by having a readout on each bug after it's done and pointing based on how much effort such a solution should take, not how long it took, but readouts on every bug would add process where there doesn't need to be process and waste time.
I'd greatly appreciate opinions on this from others here.
The Scrum Guide states the following as the opening statement in the section that describes the Product Backlog.
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Do the bugs need to be addressed in order to improve the product? Is it work that will be undertaken by the Scrum Team? Then why would they not be in the Product Backlog? I also want to point out that no where in the Scrum Guide does it differentiate between types of work that exist in the Product Backlog. Everything is a "product backlog item", not a story/bug/task/etc. So, my recommendation is that you treat all work that is needed to improve the product exactly the same. Put it in the Product Backlog. Refine the item so that the work is understood well enough to determine if it can be fixed during a single Sprint. Let the Developers pull the item into a Sprint where it will support the Sprint Goal or allow for extra work should they satisfy the Sprint Goal.
The mistake that everyone makes is using the functionality that the computer software gives you to create and manage things differently. That just adds unnecessary complications. Keep it simple.
I am not going to go into a discussion on using points to show where work was done. There are many posts in these forums where I have stated that along with others.
Recently, there has been a push from one developer to also point unpredictable and unplanned work, so as scrum master I'm wondering which way to go.
The Product Backlog should tell the truth at all times about how much work the Developers currently believe remains for the Product. If they don't take defects and rework into account, it will no longer tell that truth.
Estimation, whether you use points or something else, isn't to "show where the team's time went". Estimation is part of planning, or helping the team to figure out what is achievable so they can make appropriate commitments.
I would take that approach. What helps the team make reasonable, appropriate, and achievable commitments? That could be pointing bugs, not pointing bugs, or taking a general No Estimates approach and dropping estimates entirely. And you don't need to drop estimation to drop estimates - you can still use estimation techniques to check agreement on right-sizing well-defined bodies of work.