Sometime back, I heard someone saying- “My team is not doing that good because it delivers only ‘X’ story points whereas other teams deliver more than that!!!”
This is one of the things we witness while working in the agile environment. The team might start comparing user story points delivered other team and this is not the good indication for agile culture. Sometimes this comparison might end up in
a. Motivating the team and deliver more
b. Might end up in discouraging the team and deliver fewer
c. or team itself may start overestimation of story points
Point ‘a’ is still good but may not be the case always. If it is resulting in ‘b’ or ‘c’, then it is the indication of degrading agile culture in the team
Background for new readers:
Traditionally, efforts for the development are estimated in hours, days, months or even resources. One of the popular method followed in the scrum is to estimate user story is using the Fibonacci-like format: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Some call this method as ‘planing poker’ estimation. This estimation is done with the relative comparison to your ‘OWN’ work. For example, the simplest story you develop is you consider one point, and the story to be estimated will be how much points will it be.
What is good about this method:
This method challenges the team to make more tough decisions and encourages collaborative culture among the team. While estimating, everybody thinks about all the things need to be done to deliver that story. This includes efforts taken by other team members also. Hence, it helps everybody on the team to:
1. Think about the end to end development approach from the scratch
2. Motivates collaborative culture
3. Estimation includes all the things needs to be done to deliver the story, includes nondevelopment work also- like meetings, emails etc
4. Encourages the team to be autonomous and self-disciplinary
What are we doing wrong? or What we should avoid doing?
1. Comparing velocity of one team to another:
This is very common to most of the teams. They end up saying my team delivered X points which are more than another team.
This may not be true, because story point estimation is very much team specific and based on the various factors, such as
1. Skill/experience level of the team
2. Judgment- One team might feel the story is difficult to develop whereas other teams might find it very easy
3. Maturity in the agile estimation- Team who are more mature and having the precise understanding of agile- they tend to estimate stories very precisely
Yes, comparing your story points to other is not correct. This is just to push yourself to next level.
2. Do we add points by individuals to estimate the story
Another thing we might end up doing is estimating the tasks and adding them together. For example:
There is a story having front-end development, backend development and testing involved. These three roles just add their work estimation together to come up with the ultimate story points.
This might work well for some projects but ultimately it does not satisfy the purpose of ‘Relative Estimation’. This doesn’t motivate the team to be thoughtful about that story
3. Average out the story points
Sometimes some team members come up with the extreme numbers from the pokers scale. For example, one says 3 whereas another says 8. In this case, sometimes we end up taking 5 or averaging it.
This might not be the correct way to it because the team member, who has estimated it as 8, finds his task time consuming and from his perspective that’s the right estimation. Ultimately, his work becomes the bottleneck and story might not be delivered.
So, it’s not the good idea to average the story points.
‘Story point’ estimation is excellent and more productive when it is done correctly. It is not that easy and may take time to understand the team. Gradually creating the right culture of estimation which encourages the team to be productive while not discouraging other teams- It is key to successful agile estimation