Tag: Estimation

Posted on

Should You Re-Estimate Unfinished Stories?

As well-intentioned as teams are, it’s really hard to finish absolutely everything by the end of a sprint. A team may have grabbed eight product backlog items (typically user stories), but only finish six or seven of them. The other items are often close to done, but this isn’t horseshoes so close doesn’t count.

But what about the estimates on those unfinished product backlog items? Should they be re-estimated? And should the team get partial credit for the work they did complete? Let’s consider each of these questions, starting with partial credit.
Continue reading…

Posted on

Mike Cohn’s Most Popular Blog Posts from 2020

10. Use a Pre-Mortem to Identify Project Risks Before They Occur

9. Overcoming Four Common Problems with Retrospectives

8. Are We Really Bad at Estimating?

7. Can There Be Too Much Transparency?

6. How to Estimate Story Points with Multiple Teams

5. Time Pressure Improves Productivity & Quality…Up to a Point

4. Can a Team Vote Someone off the Team?

3. 25 Questions that Will Help You Know Your Teammates Better

2. Is the Distinction Between Outcomes and Output Overdone?

1. Are Estimates Ever Helpful to Developers?

Posted on

Throw the Cat.. and other objects

I copied this exercise from: https://www.tastycupcakes.org/2016/05/throw-the-cat-and-other-objects/

Timing: 10 minutes preparation, 15 minutes to run then as long as you need to debrief

Materials:

Stickies, Pens and a list of objects

Instructions:

I’ve started using this as a variation on the https://www.scrumalliance.org/community/articles/2014/may/title-teaching-relative-estimation-by-throwing-a-c example by Tomasz de Jastrzebiec Wykowski.

The basics of it involve getting the team to discuss the relative estimation of achieving a task. I’ve found this really useful for new members to the team to understand that a 13 for one team may not be a 13 for another, not due to ability but rather it all being relative to previous works done.

  1. On a wall add to sets of estimation counting, anything you like… in this case I used Story Points and T shirt sizes, so one board is the points the other is shirts
  2. Split the team in to two
  3. give each an identical pack of items, don’t look at the yet.
  4. Scenario – each object must be thrown at least one meter
  5. Place the objects on the boards using relative estimation for difficulty

I purposely selected an ambiguous set of objects, which if the team ask for clarification I’ll answer.

So this is what we went for..

  • Cat – will it just let you? will it fight back
  • Ball – it is actually a medicine ball… I just don’t specify
  • Feather
  • Rose
  • Trumpet
  • Pizza
  • Jaguar – worse than a cat… but actually the car
  • Sheet of paper – can you scrunch it? make a plane? again don’t specify
  • Stone – from Stone Henge, again don’t specify
  • Bat – Vampire kind

The actual cards are one word and ambigious

ExamplesDownload

Learning Points:

The purpose is to get discussion going and realise that there is no correct answer, By using 2 different measurements you can see first of all what one group thinks then how it relates.

Posted on

Agile Resources

I came across Andy Bacon his blog that lists some interesting articles and resources, you can find it here: https://andybacon.com/agile-resources/

And just in case he ever decides to take his website offline, here is a quick mirror 😉

Some Agile Basics

Agile Related Certifications

Scaling Frameworks

Retrospectives

Daily Scrum

Scrum Graphics

Checklists

User Stories

Role of Managers in Agile

DiSC Assessment (free)

Games

Metrics

Estimation, Data Driven Estimates, and Forecasting

Collaboration Tools

Happiness

Podcasts

Product Owner Resources

  • Opportunity canvas
  • Lean canvas
  • Product vision
  • Product roadmap
  • Release plan

Random Helpful Things

Technical Topics

Posted on

Story Point Estimates Are Best Thought of as Ranges

When estimating with story points, most teams use a predefined set of values that doesn’t include every possible number.

One of the questions I often get about story points is what to do if you can’t decide whether a particular product backlog item should be an 8 or a 13 (or a 3 and a 5). Part of the answer can be found by thinking about water buckets.

Suppose you have 10 liters of water you need to store. You also have an 8-liter bucket and a 13-liter bucket.

Which bucket would you store the water in?

The 13-liter bucket, right? Ten liters of water doesn’t fit in an 8-liter bucket. The water would overflow and spill out.

Extrapolating further, you’d use the 13-liter bucket for all amounts of water from 9 liters through 13 liters. Once you hit 14 liters, though, you’d once again need a bigger bucket.

And so it is with the values you choose to use when estimating stories. Think of each value as a bucket. A value bucket is used for all stories between that value and the next lower value.

Read the complet blogpost here: https://www.mountaingoatsoftware.com/blog/story-point-estimates-are-best-thought-of-as-ranges

Posted on

#NoEstimates isn’t crazy

Estimates are always waste; they are not our product. We wish to reduce this waste, as with all waste. Therefore we should always wish to reduce estimates. In the limit, this activity would result in “no estimates”, the famous hashtag.

We always could stop estimating, but it’s not always the right thing to do. It’s always legitimate to think about it.

Read the full post here: https://ronjeffries.com/articles/018-01ff/no-estimates-logic/