Estimating Technical Tasks in Story Points

Task Sheet bad!

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?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s