User Story

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.

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?

Scrum Backlog: Epic, User Story, Acceptance Criteria

by Avienaash Shiralige 3 Comments

Often, I get to hear questions about level of details that need to go in the product backlog stories. How detailed should be the acceptance criteria? or how small the story should be? We all know stories matures with time. I really like this post on user story life-cycle. Please take time to read this. Let’s consider an example now.

User Story example: As a Project Owner(PO), I should be able to transfer complete project ownership to my connection, with my role remaining to be just a project creator(author) after transfer.

Note: At the first sight, it is tough to say whether this is a story or an epic. When this story comes up in backlog grooming meeting, teams might completely miss the magnitude of such stories. Hence, as the product becomes bigger it is wise to start detailing stories by adding acceptance criteria earlier in grooming meetings itself. Impact of every new story gets wider as product becomes bigger which often gets missed by the team.

Story Point Mapping with Hours – Key Ingredient to Burnouts?

by ShriKant Vashishtha 16 Comments

This is based on a true story of a project I was involved in and that was also the first ever Agile projects I worked on. As I came from straight from waterfall background and didn’t have enough Agile experience, it made a lot of sense to us to map a story point with number of hours for obvious reasons. We mapped story point with ideal hours. Initially things went well. However after a few months, we started getting into difficult waters because of following problems:

We began to witness clashes among developers over estimations. As story point was mapped with number of hours, it directly mapped with the skill of a developer. For instance, a senior developer could finish a user-story in 2 hours. Another not-so-skilled developer or new-in-the-team developer could finish the same user-story in say 8 hours. That started causing planning meetings with clashes, disagreements and also spurts of indirect bullying from senior guys. As a result, not so experienced developers started spelling similar smaller estimates even though it caused them to work longer hours. As it was a distributed augmented team, we also started witnessing lack of trust within team because of those reasons.

Also customer didn’t see any significant change in team velocity even though productivity improved multi-fold. “YOU ARE NOT PRODUCTIVE GUYS…”
[Read more…] about Story Point Mapping with Hours – Key Ingredient to Burnouts?

Story Mapping and/vs Process Maps

by ShriKant Vashishtha 18 Comments

One of the key philosophies of Agile software development is to have information radiators visible on the wall so that the progress of the team as well as what team currently is working on gets clearly visible to anybody who visits to the team area. That includes stakeholders, project managers, team or anybody from the organisation.

However, haven’t you observed that many times, as you look at the card-wall (Scrum Board), things are not very clear to you. Card wall may look like the mesh of user-stories with statuses in To Do, In Progress or Done. However some of the bigger questions are not clearly answered by just looking at user-stories.