Estimation

When Story Point Estimation Doesn’t Work!

Story points are used to arrive at a shared understanding around a PBI. This works well when a team works collaboratively. Such teams take a PBI and swarm together to complete it. For instance, a front-end developer does her job, along with a designer and a back-end developer. In other similar scenarios, a team can have a mix of specialists and full-stack developers. These folks pair up and keep switching from one story to another as part of pair switching.

In all these scenarios, having a shared understanding on a PBI helps. That’s the reason why planning poker and in turn story points work.

Agile Estimation: Should We Use T-Shirt Sizing Instead of Story Points?

by ShriKant Vashishtha 1 Comment

As we have seen in the earlier chapter, it doesn’t make sense to map story points with time just because they are not the same thing. It’s like comparing apples with oranges.

Some teams may be okay with these problems and still may want to get ahead with mapping a story point with time. However some teams may want to fix that.

In my experience, the teams which are already mapping a story point with time, it becomes difficult to unlearn the mapping even if the team wants to.

Recently, in one such new team, instead of story points, we began with the idea of T-shirt size based relative estimation.

Story Points for Bugs or Defects

by ShriKant Vashishtha Leave a Comment

Generally, a sprint backlog contains bugs as well apart from user stories. In these situations, a common question is should we assign story points to the bugs.

If the team does not assign a story point value to this work, velocity will show the amount of *potential* business value the team is delivering in each sprint. This way, it becomes evident that team is going more slowly through the work than it could if legacy bugs were not there.

If the team assigns points to the bug-fixing effort, the team shows its true capacity to accomplish work. This way, it shows both *potential* business value delivered and effort gone in bug fixing part.

Should We Count Story Points for Unfinished Stories?

by ShriKant Vashishtha Leave a Comment

Unfinished stories is a smell and the root cause in general may lie somewhere else. Why don’t we try to fix the root cause first as much as possible?

This generally happens when a team practices “swim-lane Scrum”(an anti-pattern) instead of collaborative Scrum. In “swim-lane” Scrum, each team member individually takes the ownership of a story through the stages of the process. That results in WIP (Work in Process) equal to the number of team members, at any point of time.

If an individual gathers up multiple stories, or tries doing all the tasks in the story at once, you can get the context switching that comes from having too much work in progress. All that results in even higher WIP.

This higher WIP results to leakage in form of unfinished stories.

Let’s take an example. A team of three practices “swim-lane” Scrum. Each team members picks one story at a time and move that to in-progress.
[Read more…] about Should We Count Story Points for Unfinished Stories?

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.