Estimating Technical Tasks in Story Points
When planning a sprint, developers usually decide how many requirements they can adopt based on how much time they have left after system maintenance and fixing bugs. In some teams these tasks are also part of the Sprint Backlog, to emphasize transparency and make it easier to plan them.
When Teams estimate User Stories in Story Points, it is tempting to also slap a Story Point value on maintenance tasks and/or bugs for the purpose of planning future Sprints.
This is a bad practice!
And here is why:
- There might be some (overly business oriented) Product Owners out there, who will try to argue that with 20 SP in maintenance tasks and 50 SP in new functionality, your real Velocity is around 70 SP! Depending on the Product Owner, you will find it very hard to get that time back.
- Product Owners use the Velocity to plan Sprints and Releases. If the Velocity of a Team would not only represent the implementation of new functionality but also bugs and maintenance tasks, long term planning would be way off (since it is compared to new User Stories only).
If you can’t (or do not want to) estimate these tasks in hours, determining how much time you plan on spending on that task might be a short term solution. This way, the developer gets a better feel fr the complexity of the task and still has enough time to meet the Product Owner’s expectations.
What do you think?