Story pointing in very first sprint for new project
Ours is very new project and we are starting a sprint from tomorrow.
We don't have base stories to compare and decide estimation (relative estimation) for stories we are planning for new sprint.
In backlog grooming meeting today we went by following approach- :
1 story point = Simple
2 = Medium
3= High
5= Complex
8= Epic (Can't be completed in a single sprint)
Now, since we were not having any stories to compare we went by development team's gut feeling .
Is this the right way ?
We were just having 3 stories in this sprint , out of which for 2 stories developers gave 5 points and to one story 3 points. There is a possibility of exploitation of freedom by development team in a way that for 3 story points they may say 5.
So, we need to create a base for relative estimation.
How should we create it ? I hope my question is clear.
Vishal,
I think your approach is very good. Have the team make their assessments on size (best guesses) for the first few sprints, and then review what items they identified as 3's, 5's, etc. Are they consistent? Were there outliers, and if so, what were some of the reasons for the inaccurate estimation?
Your "baseline" will evolve after a number of sprints. Allow the team over time to develop consensus around how they relatively size items.
Now, since we were not having any stories to compare we went by development team's gut feeling .
Is this the right way ?
Absolutely.
I would suggest you use T-Shirt sizing this early in the game. Small, Medium, Large, XL, XXL. Get used to using this kind of estimation and then move to actual points. Your team will find the base as they continue to work on the product. In 3 months, what the team said is a 5 now, may be a 1 or 2, or it could be an 8 or 13. It is a relative number after all. Encourage the team that there is going to be failure along the journey. They will say something is a Small or 1/2 and mid-sprint it turns out to be much larger; that's okay, it's part of the journey. Go 3 sprints and then ask the team what they think of the story point structure and then compare the done stories to stories needing to be sized and see if they found their base line.
My coaching has always been that you can't change something until you do something. In the case you are posing, I think you did the right thing. You need to start somewhere and refine the practice as you acquire more data points. The team arrived at a starting point for their scale and used it.
...we went by development team's gut feeling .
Even when you have done this 1000+ times, you will still be going by the team's gut feeling. An estimate is basically an educated guess. I have never seen a way to make this a formula or exact science that is reliable. That has been a challenge for many years and none of the methods I have ever been part of were completely accurate. The hope is that over time the team's gut feelings start to become similar which helps them forecast the work that they feel can be done during a time-box.
8= Epic (Can't be completed in a single sprint)
By this, do the team mean that they can’t complete 8 points-worth of work in a single sprint, or they aren’t prepared to invest 8 points-worth of work in just one item, or something else?