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?

Never Map Story Points with Hours

by ShriKant Vashishtha 8 Comments

As long as a customer trusts the team, whatever way you size or estimate or don’t estimate, doesn’t really matter.

But that doesn’t happen very often. Whenever a customer questions about team throughput for whatever reasons, it becomes challenging to answer it using hour-based estimation as the number of hours (capacity of a team) remains constant.

Now if we move towards story point sizing (relative sizing) technique, it’s important not to map with time.

Here is why: