Monday, February 5, 2018

No-waste agile estimating session notes

No-waste agile estimating, with Ron Lichty
------------------------------------------

Everyone gets asked for estimates, but we mostly do it poorly.

"The point is not to do Agile. The point is to be effective. Agile provides us insights." - Al Shalloway.

"Simplicity -- the art of maximizing the amount of work not done -- is essential." - The Agile Manifesto

Why estimate?
  Product owner input to backlog ordering (ie the I in ROI)
  Some kind of predictability, for sales, marketing, the board, the CFO, etc.

The problems with estimating
  Software requires creative work, learning new skills, and undivided attention for long periods of time. Innovation is unpredictable.

Classic approach: break the work down to small chunks, estimate them all, take the sum. Those estimates don't work.

Exercise: I want to eat some fruit
  How much overhead is required? Overhead == time to prepare a serving, time to clean up after eating it.
  Do the estimates in a group by doing the classic approach. Try to do it in 8 minutes. Good luck with that.

"There's no sense in being precise when you don't even know what you're talking about." John von Neumann, physicist.

Scrum sizing
  Take the entire team into a room and size the entire backlog. Why?
  Multiple points of view, wisdom of the crowd, drive alignment, gain understanding of teammates, engage the whole team, etc.
  Story sizing is done relative to other stories, so it's helpful to look at all stories in relation to each other.
  Use abstract measures (story points, typically in a Fibonacci sequence), but the points do NOT equate to calendar time.
  With a measure of team velocity you can make a projection.

Many teams use planning poker. But it has issues:
  How do you start? If stories are sized relative to each other, the first story is impossible to size.
  It frequently devolves to guessing, stepping out of relative sizing.

Two-pass release sizing (aka the Steve Bockman method)
  Faster than planning poker. Guarantees stories are sized relative to each other, and provides a second-pass double-check.
  E.g.: sizing the two tallest buildings in the city from the top of Mt. Rainier. Can't say the exact sizes, but you know which one is taller. And you can estimate by how much, eg it's 5% taller.
  How to?
    Only doers participate: the people who do the work do the sizing. No product owners/managers allowed.
    1st pass: order the stories from smallest to largest.
    2nd pass: size by modified Fibonacci numbers: i.e., figure out where the break is between successive point sizes. Cards will move around some more.
    Can do it with physical cards and a big table.
    Start with 1st person putting the 1st card on the table. Pass the deck. Next person takes the 2nd card, and you place it relative to the first card. Pass the deck. Rinse & repeat: each person takes a card and places it in size order, getting consent from the group. You build a big snake of cards.
  Can do ~150 stories in about 3 hours.

  As you go, you'll learn about who has expertise in the stories, what the dependencies are, etc. Write those things on the cards.

  Sometimes there are series of stories that are related (eg add cc support for visa, add cc support for mastercard). The first one will be bigger than the others. You can mark these stories by e.g. using colored post-its to color-code the related stories; you treat one arbitrary one as the first one to-be-done and the rest as the follow-ons. Consult with the product manager/owner about which one comes first.

  What if you need research to size the story? Score it as really big, then do the spike, then resize it. But be careful -- you usually know it's rough relative size, so you can probably put it in the ranking without the spike.

Repeat the fruit overhead exercise, but with a bunch of different fruits. 5 minutes to order them, and 3 minutes to size. Be honest about doing 1 card at a time.

A neat trick to establish a team's velocity: take past stories and slide them into the sized backlog as a third pass, which gives you point values, so you can then determine velocity, give or take ~20%.

For distributed teams: this process works well, using realtimeboard or stormboard. Instead of snaking the cards though, use rows. It makes manipulation of the cards much easier.



--

==============================

Brent Miller

Principal Software Engineer & Architect

New Relic, Inc.

@foliosus


blog.newrelic.com | @NewRelic

==============================

2 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. A few resources:

    I blogged about Steve Bockman’s Two-Pass Release-Sizing technique at:
    http://ronlichty.blogspot.com/2014/08/team-estimation.html

    Steve has himself written two books on the topic:
    • Predictability, his novel (highly enjoyable - it’s a beach read) on software development and estimating (in Chapter 12, Steve describes the Two-Pass Team Release-Sizing method that we practiced and that he invented)
    • Practical Estimation: A Pocket Guide to Making Dependable Project Schedules, his 99-cent ebook on the Two-Pass Team Release-Sizing method

    I shared a number of Rules of Thumb and Nuggets of Wisdom from my book,
    Managing the Unmanageable: Rules, Tools & Insights for Managing Software People & Teams

    The book has its own Web site:
    http://ManagingTheUnmanageable.net

    I am also co-author of the Study of Product Team Performance. It’s free. I've written short summaries of each year's study and their eye-opening findings and provided pointers to where to download this year’s study at:
    http://www.ronlichty.com/study.html
    Among blog posts is this one on 5 factors that correlate with 67% of high performance teams (one of them being effective team onboarding):
    http://ronlichty.blogspot.com/2013/01/what-makes-product-teams-great.html
    I blogged on Standups, a topic in the 2015 study, at:
    http://ronlichty.blogspot.com/2015/07/the-skinny-on-standups-make-them.html
    Definitions of Done were among the 2016 study's findings:
    http://ronlichty.blogspot.com/2016/10/high-performance-teams-definitions-of.html

    --Ron Lichty

    ReplyDelete