I really hate bucket tasks, but I haven’t found a satisfying way to avoid them. We tend to have on every project things like:
- Defect Resolution
116hrs
- Update Use Cases
18hrs
- Update Rules Doc
16hrs
My best idea is to leave them off and include them in the slack typically left in a project or discover them when we actually have to do some work on them. So far the teams have been more comfortable with the bucket approach. And at the end of the Sprint the time mysteriously dries up.
We’ve been experimenting with commitment-based sprint planning, where the team takes on stories based on what they think they can can take on. This gives the team the ability to leave themselves the time they need to handle things like your bucket items. It’s working out pretty well so far.
An alternative for the use cases and rules doc might be to make them part of each story’s done/acceptance criteria.
This sure sounds like a smell.
I can think of these:
1- Bad planning. The team is not really doing design during the planning meeting, they are mostly trying to flesh out some estimates to get over the planning and start coding. I’ve seen this happening before
2- Quality Debt in disguise. The items you mention (especially defect resolution) sounds like you are constantly fighting some fires but don’t know how to put it down in the plan yet.
3- Lack of focus on delivering. “Update use cases”? That sounds like you have to deliver some documents _outside_ the development team. Use cases are supposed to be documents _for_ the dev team, not for outsiders, right? Others can actually use the software to see the if the use cases are developed correctly, right?
It can also be that these comments are incorrect. Not enough context to judge…
Let’s see:
Bad planning — possibly, we did get people to move defect resolution tasks to align with individual product backlog items this time.
Quality Debt – probably, our product owner wants to follow a perceived process and feels we must have a business analyst write the use cases. Thus the business analyst is spending a lot of time translating. Since the rest of the team is constantly waiting on baselined use cases it causes some quality issues.
Lack of focus on delivering – We have tried to argue that there is far too much focus on the use cases, but no luck yet. There’s still a concern around documentation being produced as it’s own artifact.