ShriKant Vashishtha

Who all should Participate in Story Point Sizing Activity?

There are folks who may be moving from waterfall to agile approach.

They in general divide the estimates in terms of development estimates and testing estimates. These estimates are separately done by the representatives of developers and testers. These representatives are either not part of the team or may not be doing that work.

In Agile teams, the story point sizing activity is done by the whole development team.

Just to reiterate again, all cross-functional team-members participate in the sizing activity. Also, there are no separate story points for development and testing activities which could potentially enable the team members to estimate them separately and combine them together to come up with the resultant size of a story.

What is a Story Point?

by ShriKant Vashishtha 1 Comment

Story point is a unit of measure of estimation for the overall size of the work that will be required to fully implement a user story.

Story point has no direct relation with time even though people may get tempted to map it with time in order to get an hourly estimate to complete a user story.

To understand story point concept better, it’ll help to take an analogy with distance.

Why to Use Relative Sizing?

by ShriKant Vashishtha Leave a Comment

If you draw a straight line on a white board and ask people how long the line is, different people will have different answers.

However if you ask the same folks around how long the line B is in comparison to line A, almost unanimously you’ll get the same reply, i.e. “double the size of line A”

The reason – we humans are visual people. We struggle quantifying something in absolute terms but it’s not that difficult to compare one quantity with another.

All About Story Points and Agile Estimation Series

by ShriKant Vashishtha 1 Comment

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.

One Piece Flow – Alternate of Kanban in Software Development

by ShriKant Vashishtha 1 Comment

Kanban process is based on 6 basic practices

Visualise
Limit work in progress.
Manage flow.
Make policies explicit.
Implement feedback loops.
Improve collaboratively, evolve experimentally.

If you reflect on these principles the premise essentially is to optimize the flow. Limiting WIP is a way to do that. There are no right or wrong numbers around what exactly should be the WIP limit of each column. All these numbers are bound to change dynamically and organically until the flow has been optimized.