Agile Estimation
- 1. Estimation of the user stories in agile project had been quite a difficult task for project management and so do it is more complicated for the scrum team. There are multiple reasons on why the estimation of the user stories seems to be complicated. To understand more better on what could be the limitations and issues team would face while estimating, let look in more fruit-yyy way. Project Vision: Consider project where the vision is to consume different varieties of edible fruits (yes correctly read.. fruits) so that it can be correlated with different constraints which impact the estimation. Also let us consider these are not known product which is the ideal case for any project. Given this vision and the user stories which are listed as fruits, let us see what are the various constraints and how they can be handled. User Stories: Product Owner defined the user stories the way it is mentioned below PO has clarity on what the user stories and the acceptance criteria. The acceptance criteria for all of the user stories is to consume all of the user stories with 0% wastage.
- 2. Estimation guidelines: Similarity / Size: The very first aspect team can consider is similarity of multiple user stories and see if their correlation exists, also content of the user story. Since PO is part of planning activity will be supporting in team in guiding the process of understanding the similarity of the user stories. In our example, let see how the relative size and similarity exists for different user stories. Per these criteria, it can be understood that on size plum, walnut seems to be small and jack-fruit seems to be large, also walnut, plum and grapes are similar and so it can be differentiated.
- 3. Estimation guidelines: Duration: If the user stories to be classified based on the duration that would be required to complete, as PO is being an integrated part of scrum team could define user stories which would help team to understand what would be duration of the task. Team would then be able to identify how much duration would each of the task required to be complete, let see how does this applies to our backlog. Complexity: Team most of the time will think of how correlated the user story is when compared with other related work it may have delivered earlier, this correlation will help to understand if the task involved is complex or simple. Complex user stories would mean higher story points when compared to simpler stories, in our case based on the description from the PO and conversation team can figure out that grapes/plum would be simpler to consume and jackfruit would be more complex.
- 4. Estimation guidelines: Uncertainty: In some cases, user story seems to straight forward and can able to decompose them to smaller task straight forward. There would some user stories where the work is known but when start to decompose the uncertainties would evolve which the team may not be aware of earlier. PO may clarify that jackfruit may contain 200 seeds/slices but then when team starts to work may uncover it contains 250 or more, this would mean the story would take more time and so do the points. Team must consider this while estimating and consider this factor while sizing.
- 5. Estimation guidelines: Expertise: Agile strongly recommends having cross cultural team for any project to be successfully executed. Multi- talented teams often out-perform monolithic team on execution since they have all of expertise built in. Consider in our case not everyone may be expert in carving out jackfruit or pomegranate but someone relatively better in doing this job. As in agile task are pulled by the team rather being pushed, these experts will come out and get this task pulled. This self-organizing concept will bring out real expertise to work critical task to support team in focusing on deliverables and achieving it. So based on expert judgement, we can identify the quantum of work each of the story may require and size accordingly.
- 6. Estimation guidelines: Infrastructure: For any user story to get complete team should ensure require infrastructure exists prior to committing it for sprint. The more the infrastructure need, the more size of the user story it would be. Some user stories may not require any additional infrastructure based on which team can size that to be small but then for some stories it may be too huge infrastructure would be required which will then be of larger size. So as the team discovers from PO, that Jackfruit may require more sophisticated tools for faster execution, team may then need to allocate team to ramp-up on these tools and so do the size of user story grows.
- 7. Team while estimating the stories may be not doing these classifications on paper but would be considering it will sizing. As team had analyzed the user stories on these aspects and start sizing, our estimation may look this for the product backlog Just to wrap up on how the project would be delivered, let consider the velocity of the team of 4 be 5 story points and we have total story points of 65 would mean the project will end by 13 sprints. If each sprint is of duration 8 minutes (per say) our project of consuming all of the user stories would be 104 minutes which would mean 1 hour 44 minutes…yummy…