In the first article of the blog series “What the Scrum Guide is not telling you”, our colleague Andreas explained why the “Definition of Ready” is no longer mentioned in the latest version of the Scrum Guide. Interestingly, the same applies to the terms “estimation” and “story points”. Why is that?
Similarly, estimation methods such as Story Points or Scrum Poker are not mentioned anymore. Burnup and burndown charts, as well as cumulative flow diagrams are mentioned to predict progress, but there is no explanation on how to fill them. A Scrum.org exam question aims to determine which estimation unit to use by the dev team to convert selected product backlog items into a working increment. The answer to that is also very vague, which is “any useful sizing techniques / whatever helps the team”.
But why doesn’t the Scrum Guide actually say anything specific about this?
The Scrum Guide in its current version wants to contain fewer specifications and give the Scrum team more freedom to manage itself. It leaves it up to the Scrum team to choose the tools to deliver value and meet the Sprint and product goals.
During the Sprint planning event (topic two), the Scrum Guide simply states that:
- the selected product backlog items can (if necessary) be refined (see “Clarification”)
- the development team based on their past performance, their future capacity and their definition of done (DoD)…
… can “roughly predict” what can be completed in this sprint. This comes very close to the definition of an estimate.
Sidenote: work is understood as complex and emergent. Team members should agree and commit to an achievable sprint goal, but not to any work forecast. That is the opinion of the Scrum Guide.
A bit of archaeology:
un fact: task descriptions in the form of user stories and epics do not originate from Scrum (from Ken Schwaber and Jeff Sutherland), but from “Extreme Programming” (XP). Kent Beck used this concept for the first time in 1996 (about one year after the “release” of Scrum at the OOPSLA 1995) in the form of “story cards” in a project at Chrysler. Ron Jeffries and Ward Cunningham were also on board in the Chrysler project at the time, as well as estimates in the form of “story point” units. In this project, the units were still given in “ideal developer days” (ET) and then simply converted to story points (SP), i.e. 1 ET = 1 SP.
Kent Beck then published the first edition of “Extreme Programming Explained in 2000. Embrace Change” (ISBN 0-201-61641-6), in which he explains the method framework and process model.
OK, what are the opinions and currents in the Scrum community and what are the best practices on the market?
To quote Boris Gloger: “… it’s best to leave it alone – I would like to say now. But that doesn’t help you either, sometimes you have to estimate in your projects.”
Just like user stories, estimates in story points have become established in agile practice. They are the main application for calculating the sprint velocity, which, for example in combination with a burn-down chart, can be used to carry out a “probability calculation” as to when the backlog could be processed or the software has a previously defined range of functions . This becomes particularly relevant in connection with the questions frequently asked by stakeholders about the “completion date” and the costs.
The understanding and use of story points has now sharpened compared to the 1996 Chrysler project in that story points are used as a measure / unit / tool for relative effort estimation. Relative estimation here means that in our mind’s eye we put two things in their relative size to each other, compare and weigh them up. In this context, it is important to have an “anchor”, i.e. a reference story, with which all other stories to be estimated are compared. Story points have again proven themselves as a possible unit of measurement in agile practice, namely in the “fake” Fibonacci sequence ( 1-2-3-5-8-13-20-40-100). Story points represent complexity. Complexity, in turn, can consist of many factors, e.g. risk, uncertainty, effort or the required knowledge development. The higher the score, the more complex the task.
With relative estimation, tickets/tasks/epics of a single software project of a single team are compared with each other. The comparison with tickets from other projects and other teams does not make sense in this case, since every project is different and different, as well as every team and every person.
Reading tip: in this context, we would also like to mention the book “Agile Estimating and Planning” by Mike Cohn (first edition 11/2005, ISBN 976-0-13-147941-8.)
The following can be added to the two most common estimation methods:
| Estimation Method | Tools | Estimation units | is suitable for | Comment |
|---|---|---|---|---|
| Planning Poker | Planning Poker Cards | Story Points
(“fake” Fibonacci sequence) |
|
Complexity estimation; most common / most widespread estimation method; each participant chooses the card with his/her chosen story points, at a signal all reveal their cards at the same time. This is to avoid setting an “anchor” and letting the first guess affect all subsequent ones. |
| Magic Estimation | Table or whiteboard with “baskets” (1 basket or column per story point number), or virtual collaboration tool | Story Points
(“fake” Fibonacci sequence) |
|
Suitable for larger groups (>50) and larger number of tickets (>100);
each participant receives the same number of cards and sorts them into the respective column with the assumed correct number of story points. When all cards are distributed, further rounds of “shifting” are carried out. Until all cards are assigned to the columns in such a way that all participants agree with them. If a card is moved back and forth conspicuously often, it is advisable to first remove it from the ongoing estimation process and then discuss it separately. |
Other estimation methods:
- T-shirt sizes (such as XXS bis XXXL)
- Animals (e.g. ant, mouse, frog, cat, dog, lion, cow, elephant, giraffe, whale, etc.)
- Function points (for complexity estimation)
“Trends in estimating”
Since discussing “sufficiently well” and then estimating all user stories – depending on their number – has turned out to be very time-consuming, many teams in daily business have now switched to the “no estimations” approach. i.e. it is “actually” no longer appreciated. Selected Product Backlog Items (PBI) are pro forma provided with story point-like numbers – e.g. 1 to 4, where 1 = small, 2 = medium, 3 = large, 4 = too large The exchange and communication within the team are still important in order to develop a common understanding of the PBI. Other methods such as velocity tracking or filling in a burndown chart are becoming less important.
Summary
As already mentioned in the previous article in this series “Definition of Ready”, there is no “one size fits all” for estimates either. In our experience, the application of estimation methods, as well as their specific type, depends on several factors. In this context, mention should be made of the environment (type of organization / company), as well as the maturity of the team, or the duration of the collaboration.
… and now it’s up to you!
Do you use estimation methods? If so, which ones?
When exactly (for which event, quality gate, etc.) do you estimate?
What are your experiences with your estimates?
Contact us: hello@qualityminds.de
0 Comments