John Blanco Agile Transformation Consultant The Eliassen Group Playing the Pointing Game

“Before you commission a painter to decorate your home or a mechanic to fix your car, you get an estimate from them, right? You need to know how much it’s likely to cost and how long it might take. It’s just common sense.”

- David Morris, Estimating on Agile Projects: What’s the story, what’s the point? Agenda

Old vs. New Where we came from and why we need to change Why Points? Why Fibonacci? Understanding basic units of measure

The Art of Relative Sizing Some Ceremonies around pointing

SAFe: Normalized Pointing Why Time matters

Complexity Clusters Helping the team thru the transition

Balancing Buffers, Invisible Load

Q&A Where we came from and why we need to change

BUSINESS Products VALUE Customer Delight Services Self Worth

Accountability Cadence Quality Self-governing Teams Velocity Reusability Goal Oriented Metrics TDD/ATDD/CI Clarity Predictability DevOps Synchronization

PEOPLE PROCESS TECHNOLOGY culture engineering

Scrum XP Services Roles Kanban Platforms Rituals Lean Startup Business Applications Responsibilities SAFe Development/Support

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation AGILE Responding to change over following a plan principles Foundation and Philosophy structure Where we came from and why we need to change

we started with this… Front end planning Sizing using task duration Sizing done by the elite

Uncertainty vs. Time (Boehm)

…and we forgot about this People are fickle – ideation & creativity can not be frozen Requirements harden as the product evolves Where we came from and why we need to change

we started with this… Front end planning Sizing using task duration Sizing done by the elite

Uncertainty vs. Time (Boehm)

…and we forgot about this People are fickle – ideation & creativity can not be frozen Requirements harden as the product evolves The attempt to achieve precision causes paralysis “Story points allow team members with different skill sets to communicate about and agree on an estimate.” Why Points? Why Fibonacci? Mike Cohn, User Stories Applied for Agile Software Development

In the simplest of terms, all we’re trying to do is: Leonardo Fibonacci, 1202 AD • Estimate the amount of work to do Liber Abaci • The complexity of the work Pingala, 200 BC • Any risk or uncertainty in doing the work

Story Point size represents: • Volume – how much must we do? • Complexity – how hard is it? • Knowledge – how much do we know? • Uncertainty – how much is unknown?

• We use a unit-less but numeric value (Fibonacci) that is relevant, i.e., 1, 2, 3, 5, 8, 13, 20…

• We attempt to triangulate with other stories, that is, an 8-point story is expected to be four times as big as a 2-point story The Art of Relative Sizing

when does pointing occur • During Iteration-0 when the initial product backlog is built • Whenever a new story is introduced into the backlog • Point refinement may also occur during Sprint Planning (normally day one of each sprint) as tasks are identified, assigned and estimated in hours

Planning Poker | T-Shirt | Affinity…

Planning Poker Variation Chris Sims of Agile Learning Labs sums things up like this:

• Start with a pile of stories, each written on an index card or sticky note. Identify one story that is of “average” size, not one of the biggest, not one of the smallest. • Find a wall large enough to line all the stories up from left to right in a single row. (This could also be a large table). • Take the “average” story and stick it on the wall (or table), right in the middle. • Pick up a second story—any one —and if bigger, stick it to the right side, and if smaller, stick it to the left. This relative sizing is done with the entire team (developers, testers, etc.) • Keep doing this with each story, swapping them around and putting them in size order, until you’ve got them lined up smallest to largest. • Then apply your numbering system, like Fibonacci. “If I want to average 32 points a game, I can do that easily. It's just eight, eight, eight, eight. No problem. I can do that anytime. That's not being cocky. That's confidence.”

SAFe: Normalized Pointing - Patrick Ewing

Velocity using Capacity SAFE technique: The SAFe normalized Story Pointing • For each sprint take the number of team estimating approach offers an 1. Anchor to One: Identify a 1- members, discounting the Scrum Master effective alternative for point story. A story that can be and Product Owner, and multiply that pointing, as it: developed and tested in a number by 8 • Example: 5 team members (3 developers and single day. 2 testers) times 8 = 40 • connects the team’s sprint 2. Relatively size every story to that load to the team’s velocity 1-point story using Fibonacci, • Using that starting velocity of 40, subtract i.e., 1, 2, 3, 5, 8. for holidays • creates uniformity for teams 3. Split any story over 8. • Example: a holiday will mean subtract 1 for joined together on the same each member on the team. In this case if there was one holiday, you’d subtract 5 from ART (Agile Release Train) by 40 = 35 establishing a common unit of measure and style • For personal time subtract 1 point for each person taking a day off. • Example: If Judy is taking a personal day to see the doctor, that’s a minus 1. If Tiger is taking a day off to go golfing that’s another minus 1. The 35 minus 2 = 33. That’s your velocity for your sprint.

• This can be used to on-board new people or part-timers.

• You can accomplish the same thing by using a spreadsheet calculator. Here we start each person out at 8* - if there were holiday we would start each person at 7. The Out column subtracts for individual personal days. * In a 2 week sprint we do not have 10 days of development and testing. We only have 8 after taking 2 days off for ceremony. “Unfortunately, typical Scrum practices around estimation tend to minimize “time” to a point of being either trivial or unimportant, when truly that is not the case.” - Me (A SAFe sentiment) Complexity Clusters (Elatta Method)

At your Story Grooming session:

1. Have the team decide on the appropriate Analysis UI/Interface Business Logic (Code) Testing Complexity Buckets suited for the type of work they’ll be doing. Consider: Consider: Consider: Consider: - Time to review any - Number of screen - Number f business - Functional tests specs fields rules (ACs) - E2E tests 2. Review each story through each Complexity-lens, - Time to meet with - Screen validation logic - Business rule - Regression tests SMEs - Number of screens complexity - Parity adding the appropriate value you feel that - Number of end-points - Automation bucket will take.

a. Some teams use a Low=1, Medium=2, Integration Configuration Deployment High=3, and Extremely Complex=4 rating. Consider: Consider: Consider: b. Some use Fibonacci 1, 2, 3, 5, and 8 - Number of Systems to - Environments - Communication rating. integrate - Complexity - Steps c. I prefer using estimated hours. - Complexity of - Access - Externals integration - Externals 3. As the team runs through the stories and estimates time for each bucket, add up the hours across the Complexity Buckets and divide by 8 (for the number of hours in a work day).

4. The resulting number is then rounded up to its nearest Fibonacci value. “You are allowed to feel messed up and inside out. It doesn’t mean you’re defective – it just means you’re human.” - Anonymous

Balancing

Things to consider when factoring in Defects and other work:

• Passion and Over-zealousness. Teams tend to over- commit and under-deliver. Point conservatively.

• One Size Does Not Fit All. No teams are identical. They are often made up of different skill-sets. Some teams suffer from only a small amount of bugs while others are drowning.

• Consider all Activities. That may mean refactor work, spiking*, and maintenance. • Create Full Load Transparency. If necessary, create Production Support stories to cluster defects into a measurable “pool”. Tally the estimated hours (per defect) and assign an equivalent Fibonacci estimate. a. Benefit: This will permit the team to visualize the complete iteration load and improve commitment accuracy.

• Factor in Remediation Time. Don’t estimate on only “happy path” development. Factor in the full cycle times of story development (WIP). Possibly apply a Pert calculation when estimating [WC + (4 * TC) + BC] WC = worst case; TC = typical case; BC = best case. a. Benefit: This allows for a more accurate story estimate rather than relying entirely on exorbitant or “catch-all” buffers.

* A spike is not a buffer for hiding miscellaneous work. Point your Spikes. No more than 3 points (24 hrs). And every spike should deliver something tangible. Balancing: Tips and Bad Habits

• Don’t separate points by skill to arrive at your estimate. “We must recognize that estimates are relative and certain skills do overlap. This is why members can, and should, place a single estimate on their stories and arrive at those estimates as a team.” Mike Cohn • Do Task With normalized pointing, tasking provides an opportunity to correct estimates before committing stories to a sprint. • Only the people doing the work should be estimating the work Using only managers or experts in estimation creates false estimates and unrealistic expectations. • Split Sooner not Later Split strategically - not due to having bad estimates when you started. Use sprint planning to refine your points. That’s when you know who’s doing the work. • Don’t allow the “tool” to drive the process Many tools have short cuts and features that help you smooth the rough spots like carry-over stories by splitting or cloning. These are useful in administration but don’t let them hide your technical debt or you’ll never get better. Q&A John Blanco

Agile Transformation Consultant The Eliassen Group [email protected] 631-418-7144