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.

Scenario 1

What about a scenario in which each individual is assigned to work on a specific list of PBIs as part of the planning? So a developer works on one specific area. Another developer may be working on another techno-functional area and in general they don’t collaborate with each other.

In such cases, instead of a team you see individuals stacked in a group working on completely different items from one another. These team-members in general don’t have any idea on the detailing of areas other people are working in. Also they may not show any interest for those areas just because it doesn’t concern them.

In all such cases, people who are assigned PBIs to work on, estimate on their own.

Instead of looking at a team’s capacity, individual capacity is looked at and based on that, individuals are assigned PBIs to work on. As estimation is not a shared understanding exercise anymore, it doesn’t matter if they estimate in story points, in days or anything else. In the name of story point, people map a story point with time (e.g. 1 story point = 4 hours) to simplify matters for them.

Such teams may be violating so many things at the same time:

It’s a typical command and control setup. Such teams are not self-organizing ones.
Developers are assigned work. They don’t pull work from the team board.
Their stand-ups in general are more of status-update meetings.
People may not be working as a team. They just may be a part of a group of individuals which is termed as a team.
As there is no knowledge sharing/management among team members, people leaving such teams becomes a painful experience for these teams.
Such teams may have a narrow perspective in terms of understanding of the PBI, its design as the rest of the team members may not be collaborating together.
Such teams don’t work towards a Sprint goal.

In such scenarios, the idea of using story points doesn’t really help.

Scenario 2

There are teams which may be slicing their work at such a fine grain level that any story doesn’t stay bigger than couple of days. In such cases though collaborative discussion on PBI still helps, story pointing may not be required just because all stories are of similar size. That’s the idea of #noestimates.

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.

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.

Rather than using numbers in the fibonacci series, here, Items are classified into t-shirt sizes: XS, S, M, L, XL.

In the planning-poker exercise as well, instead of using fibonacci numbers, we used T-shirt sizing. Surprisingly everybody got the idea without any problems just because T-shirt sizing seems to be all about size and not about time.

These T-shirt sizes can further be mapped with story points. So XS becomes 1-2, S becomes 3, M becomes 5, L becomes 13 and XL becomes 20. Anything beyond, has to be broken down further.

I find it helpful to use T-shirt sizing instead of numbers as everyone in the team seems to get the message clearly.

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.

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.

When a team gets a load of legacy bugs to fix in its backlog, it makes a lot of sense to assign the story points to the bug fixing effort.

On the other hand, for bugs found in the current user story /functionality it doesn’t help to assign story points to these bugs. Some of these teams fix the critical/high/medium priority bugs in order to move the story to DONE. Rest of the unresolved low priority bugs move to the Product backlog or to the next sprint based on the prioritisation from Product Owner. These bugs don’t get any story points.

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.

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

Deleted:

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: