Agile

Story Points for Bugs or Defects

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

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:

How to Forecast the Number of Story Points in a Sprint?

by ShriKant Vashishtha 2 Comments

Question – Estimation in the form of anything else other than time may be helpful, but we can’t use it to answer questions about when a project shall be delivered.

In our previous post, we saw that Story Point is all about the relative size of a Product Backlog Item (PBI) which depends on the amount of the work involved, complexity and uncertainty/risk. This relative size remains same irrespective of the person working on it. Essentially

Story point is about relative sizing and not about relative effort.

Effort for any piece of work varies from person to person. One senior guy may finish a task in an hour, while an inexperienced guy may take a full day to complete the same task.

If story point has no relation with time, how do we get to know the number of story points a team should be able to forecast to accomplish?

In this post, let’s see how to do that.

Begin with a Guess

When a new team doesn’t have any historical data available around its velocity, the sprint forecast can be done based on a collaborative guess from the entire team, i.e. how many story points the team may possibly deliver in the first sprint.

This estimate can just be a collaborative guess or can be more elaborate for some teams, i.e. identifying sub-tasks of the PBIs, assign hours to them and then find out if the resultant number of hours are within the team capacity or not.

Remember, there is no right and wrong method as both methods will have a variance of 50% of meeting the sprint goal, i.e. the team will have a 50% chance of accomplishing the sprint goal and vice-versa.

How to do Story Point Sizing with Planning Poker?

by ShriKant Vashishtha Leave a Comment

Story point estimation is all about relative sizing. In order to compare the amount of work of one story to another, we need to identify a base story in order to define the base story point size.

It will be important to know that story points follow fibonacci series and have 0, ½, 1, 2, 3, 5, 8, 20, 40, 100 numbers. So when we talk about a base story, we essentially are talking about a one story point story.

A Base User Story

A base user story is the smallest possible piece of work that delivers business value to the user.

As an example – a team may decide that on a search screen, adding one additional field may be the smallest piece of work for them.