Agile Estimation & Sizing

Agile Estimation & Sizing Introduction (v1.0)

Today Welcome Purpose Estimating & Sizing in Agile Points & Planning Poker Exercise 1 – Planning Poker Break Planning and Execution Exercise 2 – Estimating for Real Summary Q&A Evaluation

Welcome

Video recording Weintend to video record the training so wecanimprove as trainers. Do you have a problem with this?

Turn off your mobile phone • Shut down your computer • Focus your attention Out of Service

Safe space for learning Please help the learning process by respecting the following: We are all here to learn We do not place judgment No questions are stupid when they help us to learn It will be great if you can also promise each other that: Whatever happens in the room, stays in the room

Some basic rules If you see someone with their hand in the air: Be silent Raise your arm If a question is blocking you from learning or understanding, then please ask. If we can answer it, we will. Else we will write a post-it, and address it at the end of the section If you feel uncomfortable asking a question in public, then catch us during a break

Who’s who

Purpose

Estimating and Sizing Workshop • This half-day workshop will familiarize participants with the “Planning” and “Execution” Agile estimation approach: • For “Planning” the approach for estimating Epics, Capabilities and Features will be discussed, with hands-on experience of estimation techniques, such as “planning poker”, provided; • For “Execution” we will look at estimating techniques for Stories and Tasks using Story Points and Hours respectively.

Why we are here? • The purpose of this training is to: • Understand how estimating and sizing is done in agile • Introduce the concept of “points” and planning poker • Undertake a practice sizing session • Explain how sizing differs across the backlog items • Planning – Epic, Capability, Feature • Execution – Story, Task • Illustrate sizing in the context of the wider agile delivery process • .

Learning Objectives for this training We will answer the following questions: • Who does sizing and estimating? • What are points? And How do you play planning poker? • How is sizing different between planning and execution?

The Question Board ?

Estimating & Sizing in Agile

Agile Estimating Nobody can predict the future – so why do we force people to? In Agile we estimate by size not by time Sizing is “relative” and not “absolute” Sizes can be measured in various ways e.g. “Story” Points Points are just a number We use past knowledge We use expert advice Remember – It’s just an estimate!

The Team doing the work are the best people to size the work! The SM does not normally estimate but facilitates the estimating process The PO does not estimate, but should be on hand to clarify questions

Scrum Process in Nordea PI meeting Estimating is either part of Product Backlog Refinement, or can be a separate “ceremony”

Estimating is done on “Units of Value” and “Units of Work” 6 Levels of Backlog Element: • Initiative– strategic direction for Business impact • Epic– set of features enabling value • Capability– single valuable, generic functionality • Feature– that valuable functionality on 1 channel • Story– 1 aspect or usage of a feature • Task– an activity performed to realize a story Units of Strategy … Is refined into 1 or more … … Is refined into 1 or more … Units of Value … Is refined into 1 or more … … Is refined into 1 or more … Units of Work … Is refined into 1 or more …

Sizing is Abstract & Relative • We use “Bigness” or general size • Sizing is unit-less but relative • We use numeric values (not T-shirt sizes) • Ideally triangulate the stories being sized • A base-line can be established

Points & Planning Poker

Points Points can be used at any level of the backlog “Story Points” as the name implies are used for sizing the “Story” unit of work “Epic Points” apply at the “Epic” level,etc. The “Task” unit of work can also be sized but this is often using “time” as the currency (e.g. hours) Points were created by Mike Cohn of Mountain Goat Software Points are numeric, which can help with commitment and velocity calculations Remember they are just a number…...

Point Definition

Points – Questions to Consider Complexity: How many parts or components are involved? Are we using new technologies or skills? How many stakeholders do we need to consider? Are there any regulations to comply with? Uncertainty: Have we done this before? Do we know who is involved? Are there pre-existing guidelines and standards we can follow? Do we have the skills in the Team? Effort: How much work is involved? How many people will it take? Do we need to time for preparation and completion? What about meetings? If all of these are “High” then score with a high number, if all of these are “Low” then score with a low number

Planning Poker 1 • Iterative objective approach to estimating • Showing cards at the same time allows everyone free say – avoids domination by influential people • Encourages questions (why so high/low?) • Collaborative approach, emphasizes the team • Avoids one persons view of time with the team’s view of size • Everyone’s opinion is heard • Quick (and there are quicker methods) • Information is shared – treat as a learning experience

Planning Poker 2 • Steps: • Each estimator is given a deck of cards, each card has an estimate on it • Product Owner reads a story and it’s discussed briefly • Each estimator selects a card with their estimate • Cards turned over together • Discuss the differences (especially outliers) • Re-estimate until estimates converge

Planning Poker 3 • Fibonacci sequence cards are used • The Fibonacci sequence: • Every number after the first two is the sum of the two preceding ones • High numbers get large very quickly - the idea is that the larger the story is, the more uncertainty there is around it and the less accurate the estimate will be • The gaps between the numbers imply that you are forced to make a choice between the less/more uncertain stories • Stories are either the same, larger, or smaller, there is no “just bigger” or “more or less the same” • The human mind 'sees' a perceptible difference between 5 and 8 story points (or 13 and 20) than it does with 5 and 6 or 10 and 11. • No sitting on the fence!

Exercise 1 – Planning Poker

Exercise:Lets play planning poker

TO BE PRINTED FOR EXERCISE

Break: 30 Minutes

Planning & Execution

Estimating on “Units of Value” and “Units of Work” • Epic – set of features enabling value Unit of Value Epic estimation is done by Product Team Fibonacci, smallest Epic is 1 (the baseline) Planning poker

Estimating on “Units of Value” and “Units of Work” • Capability – single valuable, generic functionality Unit of Value Capability initial estimation done by Product Team and Development Team Representative during Capability to Feature breakdown Also Fibonacci Planning poker

Estimating on “Units of Value” and “Units of Work” • Feature– that valuable functionality on 1 channel Unit of Value Feature initial estimation done by Product Team and Development Team Representative during Capability to Feature breakdown Refinement done by Development Team during Feature Refinement sessions Also Fibonacci Planning Poker

Estimating on “Units of Value” and “Units of Work” • Story – 1 aspect or usage of a feature Unit of Work Story initial estimation done by Development Team during PI Refinement (task breakdown) done by Development Team during Sprint Planning Also Fibonacci, smallest Story is 1 Planning Poker

Estimating on “Units of Value” and “Units of Work” • Task – an activity performed to realize a story Unit of Work Task estimation done by Development Team during Sprint Planning Estimated in hours Used to verify Story sizing and Capacity planning

Exercise 2 – Estimating for Real

Agile Estimation & Sizing