Issues Estimation

In Elastio we use Planning Poker to do estimations. In the beginning of each sprint, the team should make sure that all tasks planned for the sprint are estimated.

Bugs and issues that occur in the middle of the sprint do not get estimated for 2 reasons: not to take time from the team's work, and not to distort the team's velocity. Any urgent bugs or other work which comes up during the sprint and requires engineering attention is, by it's nature, not predictable. Such tasks should not count towards the team's velocity because the velocity is a measure of the amount of planned work accepted in scope at the start of the sprint a team can execute. For example, in a hypothetical (and dysfunctional) scenario where half of a team's engineering capacity is spent dealing with urgent bugs as they come up, that team's velocity should be 50% lower as a result of all of that unplanned work. If management is unhappy with the lower velocity then management should address the large number of unplanned work items.

We use Fibonacci sequence for our estimations: 1,2,3,5,8,13,21,40. Each team should have a set of reference issues to make their estimation process easier and more transparent. Reference issues are normally defined when the estimation process through story points is implemented. In some cases, where rapid team growth occurs and as the team settles in the estimation process the reference issues might be redefined. However, it is not recommended to do so more often than once in 6 months, as the new reference issues might make past velocity data irrelevant.

Planning poker (also called Scrum poker) helps agile teams estimate the time and effort needed to complete each initiative on their product backlog. The name from this gamified technique is planning poker because participants originally used physical cards. These cards, which look like playing cards, estimate the number of story points for each backlog story or task up for discussion.

Each team has a session of Planning Poker in the beginning of the sprint, the whole team (in rare cases - some amount of people working on the same functionality/crate) is needed to estimate. Normally, one member of the team would explain what work needs to be done in the scope of the issue, then the team members are asked to put the amount of story points for the task. When all team members have places their votes, the cards are revealed.

If the number of points for the issue differs a lot, team members having placed the biggest and smallest estimate should explain the reasoning behind the estimate. As a result of this discussion team members should reach a unified decision about the amount of story points the issue is worth. If that's not the case, the assignee for the issue has the final word.

A story point is a metric used in agile project management and development to estimate the difficulty of implementing a given user story, which is an abstract measure of effort required to implement it. In simple terms, a story point is a number that tells the team about the difficulty level of the story. Difficulty could be related to complexities, risks, and efforts involved.