In a scrum framework, there are typically three types of users namely Product Owner, Scrum Master and Developers. The initial requirement gathering from the client is followed by segregating it into Epics and the User stories. This job is effectively carried out by the Product Owner. The Product Owner is responsible for the sprint planning taking into account the sprint duration, available resources and priority for user story delivery.
The Product Owner comes into the picture at the time of Sprint planning and is also responsible for giving the module demonstration to the client. Many times, a discussion with the client to freeze the priority of the user stories is also carried out by the Product
Some definitions to look at:
User Stories – Once all the requirements are gathered, the same is captured in the Product Backlog. However, the user stories are not too detailed but a brief description of it is covered. Bugs are also covered in the Product Backlog.
Product Backlog – It is a collection of user stories, maintenance tasks related to technology upgrade and bugs to be considered for
Sprint Plan – Product Backlog is then taken up by the developers for a detailed discussion. After the detailed discussion, the stories are shifted into sprint plan which is then acted upon and completed as desired in the sprint plan.
Methods to estimate sprint:
A Dedicated team to work with Product Owner –Advanced planning of the sprints months before the actual sprint starts is also utilized by companies to avoid poor sprint planning. It not only helps in forecasting the product development but also gives the client facing teams a chance to demonstrate modules and gather their reviews in terms of enhancements which will later be captured as User stories in
Formula based approach:
Cone of Uncertainty – This term is widely used in Software Development where a little information regarding the project is available in the beginning. The rapidly changing
A simple formula will help us calculate the number of sprints needed to complete a project.
i = e/v, where i = number of sprints, e = number of user stories, v = planned velocity
It is assumed that while calculating Planned Velocity i.e. v, we use estimated velocity which can be determined based on the team’s past performance or a mere guess in case of new projects. The Fudge factor, however, is taken as 0.6.
Planned Velocity = Estimated Velocity * Fudge factor
Let us take a small example and calculate the number of sprints for a duration of the
Planned Velocity = 20* 0.6 = 12
So, your release plan for all of the Product Backlog Items would be:
600 / 12 = 50 Sprints
You then turn this into a calendar or time estimate with:
50 * 2 = 100 weeks
Based on this information, your project schedule will state that it will take approximately 50 weeks to ship all the features currently in the Product Backlog. This is an estimate based on the information currently available and should be treated as a planning value rather and not a final figure.
Tracking Sprint Plan – It is only after the 2/3 of the sprint plan is achieved that one can be sure of the module delivery scope in that sprint.
