In this topic, we described about the below sections -
What is Estimation?
Estimation is the process of approximation of a value that can be used for some purpose even if input data may be incomplete, uncertain, or unstable.
In Scrum projects, Estimation would be done by the entire team during the sprint planning meeting. The main objective of the Estimation is to consider user stories for the sprint by the ability of the team to deliver during the Time box of the sprint and by the priority.
Product owner would make sure that the User stories that are prioritized are clear, they can be subjected to estimation and they would be written on top of the product backlog.
As the "responsibility to deliver the product increment" would be totally on Scrum Team, special attention would be paid in selecting the user stories for the sprint based on size of the product increment and the effort that is required to do the same.
Role of Product Owner in Estimation Process
Product owner in Agile Development would be responsible in prioritizing the backlog. He would capture the Business requirements. But, the product owner would not understand the implementation details. So, a good estimation would give the product owner a new perception into the level of effort for each work item.Product owner in Agile Development would be responsible in prioritizing the backlog. He would capture the Business requirements. But, the product owner would not understand the implementation details. So, a good estimation would give the product owner a new perception into the level of effort for each work item.
For Product owners, the task of breaking the work items into granular level and estimate them using story points would help them prioritize all the work areas. Once the development team provides estimates, the product owner would record the items on the backlog.
In this topic, we will discuss about two scrum estimation techniques. Those are -
- Story Point
- Empirical Process Control
What is a Story Point?
Story point is an effort estimation that is influenced by the complexity, amount of work, uncertainty and risk. Story points are a unit of measure to express an estimate the total effort which would be needed to implement the product backlog item fully.
When story points are estimated, a point value would be assigned to each value of the item. Raw values are often not considered. "Relative values" are considered.
What would go into a story point?
As the story points represent the effort to develop, a team's estimate should include every single thing that would affect the effort. They would include:
- The amount of work that has to be done.
- The complexity of the work.
- Any impediments in completing the work.
If a team's definition of done includes Automation tests creation to validate the story, the effort in creating those tests should be added in the story point estimate.
Story Point Vs Hours – Traditional software would provide the estimates in a time format - days, weeks, months. But now, many Agile teams have changed using Story points. Story points would rate the relative effort of work in a Fibonacci series : 0, 0.5, 1, 2,3, 5, 8, 13, 20, 40, 100. This technique would be helpful as it pushes the team to make tougher decisions around the difficulty of work.
Why use Story points?
- For non-project related activities, dates would not come into account which inevitably creep into our days - meetings, emails and interviews that a team member might be involved in.
- Relative estimation would cut out the emotional attachment between the dates and non-project related activities.
- Every team would estimate work on a bit different scale which means that their velocity would be different naturally.
- Once relative effort of each story point value is agreed, points can be assigned quickly without much discussion.
- Story points would reward the team members for solving the problems the toughness, not on the time spent. So, this would keep the team members focused on shipping value rather than the spending time.
Empirical Process Control
In Scrum, decisions would be made based on experimentation and observation rather than on detailed upfront planning. Empirical Process control would depend on three main ideas of transparency, adaption and inspection.
- Transparency – Transparency would allow the entire process to be viewed by anyone which would promote a transparent and an easy flow of information throughout the organization. It would create an open work culture. In Scrum, transparency is represented through:
- Project Vision statement.
- Prioritized Product Backlog.
- Release Planning schedule.
- Sprint Review Meetings.
- Daily standup meetings.
- Information Radiators
- Burndown chart.
- Scrum board.
- Inspection -
Inspection in scrum would be depicted through -
- Usage of Common Scrum board and other information radiators.
- Collecting feedback from the customer and other stakeholders during the Epic development, Product Backlog creation and conduct Release planning process.
- Inspection and approval of the deliverables by the Product owner and the customer in the Demonstrate and Validate Sprint process.
- Adaptation -
Adaption would happen as the stakeholders and Scrum core team learn through the transparency and inspection, then adopt by making improvements in the work they are doing. Adaptation in scrum would be depicted by -
- Standup meetings.
- Constant Risk identification.
- Change Requests.
- Scrum Guidance body.
- Retrospect Sprint Meeting.
- Retrospect Project Meeting.