Estimation

All About Story Points and Agile Estimation Series

Lots of Scrum teams have been using story points and planning poker for relative sizing.

However, this is one of the concepts like pointers in C, which troubles most of the teams and they all have their own interpretations on the subject. Lots of material has been written. However it becomes difficult to join all the dots together for any team-member to digest at one place. This series of posts is an attempt to simplify learning and make the concept as clear as possible.

Some of the posts were written in the past and some I am writing now in order to have completeness around the subject. This list will keep getting updated as I write new posts on the subject.

Our Sprint Velocity Never Seems to Change. We don’t Know Why!

by ShriKant Vashishtha 2 Comments

Story point is about size, not about time.

At best it can be about a range of time but not about absolute time. In many teams people map story point directly to time and may get into vicious cycle towards burnout.

Let’s try to understand why.

Let’s say, the team mapped 1 story point to 1 day. As they do that, the team velocity becomes almost constant. The reason being, the team capacity in terms of number of days remains constant.

As team mapped 1 story point to a day, the story points to be planned or achieved will always be around the capacity (number of business days available) of the team.

Management folks may complain that team throughput is not changing. Throughput might have already changed but it will never show up.

Instead of completing 10 similar sized stories, team may be finishing 14 already but that will never reflect as number of days required to accomplish them remain constant from sprint to sprint.

So never map a story point to time unit as that will create more problems than it solves.

More on Story Points and Agile Estimation

This post is a part of a blog post series on story points and agile estimation. To read rest of the posts on the subject, please navigate to All About Story Points and Agile Estimation Series.

Planning Poker is NOT about Agile Estimation!

by ShriKant Vashishtha 3 Comments

One of the popular mechanisms to estimate story points as a team is planning poker exercise.

It’s an awesome technique but it may become a challenge for some teams. For instance, a team estimates story points separately as developers and testers. Later, they add up those points to arrive at resultant estimates.

Some teams get into endless discussions to ascertain if the estimate should have been 2 or 3, 5 or 8 or maybe 7.

It looks like, the primary goal of planning poker exercise is to arrive at the correct estimate.

But that’s not the point!

FAQ: Why Story points? Why not map story points with time? What’s the issue?

by ShriKant Vashishtha 3 Comments

As long as customer isn’t interested in throughput or customer trusts the team, whatever way you size or estimate doesn’t really matter. But that doesn’t happen very often. Whenever customer questions about team throughput, it becomes challenging to answer using hour-based estimation as time taken to complete any particular task deflates over time.

Some teams follow capacity based estimation technique where they identify the number of hours available in a team for the entire sprint duration. Based on that they pick up stories in a sprint. Again here as well, there is absolutely no way to know any change in team throughput as size for which capacity is defined isn’t defined.
[Read more…] about FAQ: Why Story points? Why not map story points with time? What’s the issue?

Agile Contracting: Discovery, Fixed Budget, Variable Scope

by Avienaash Shiralige Leave a Comment

We discussed about committing fixed number of story points and swapping any additional scope with existing backlog in our previous post “Agile for Fixed Bid Projects“. This is a great way to maximize value with minimal change in timelines and budget. This works well when there is a trust existing between product and engineering, and client/product team understands this agile approach. Still, fixing size, undermines one major aspect of an agile team – “applying learning back into the project”. Development teams while doing size estimation give higher points where there are uncertainties and risks. Known unknowns, new technology, unclear requirements etc. are few reasons for providing higher story points. As project progresses, teams get more knowledgeable (both technology and business) and hence some tasks now look smaller than before.