To estimate or Not to estimate

#21

RE: limit the size of stories

The team I’m currently SMing I told them “No more 8s!” which a sprint or two later became “No more 5s!” which is now becoming “No more 3s!”. I realize this isn’t realistic for everyone but it’s really helped the team mature; their velocity is steadily improving, they predictably deliver on what they commit to, and we’re pulling work in by the handful.

We do however estimate tasks; the team told me that they prefer to do this because it forces them to think even more granular. During grooming I’m seeing more and more instances of “what about task x, y, and z?” and then “this is too big, let’s split it up”…coaching themselves. It’s a beautiful thing!

#22

Perfect timing: Stay tuned for an upcoming podcast on Dynamic Reteaming w Heidi Helfand!

Sneak preview:

  • Our discussion challenges the notion that we need to keep our software develop teams “the same” in order to be successful.
  • And instead, as agilists and coaches our goal should be helping teams to self-reflect and shift from working in silos to working as cohesive and perhaps non-persistent teams.
  • In short, to help them dynamically reteam, of their own volition, when there’s value and wisdom to be gained by doing so.

Heidi Helfand - Dynamic Reteaming https://leanpub.com/dynamicreteaming

#23

That sounds like fun!.

#24

Another way I like to think about the question of “to estimate or not to estimate” is what is the opportunity cost of the effort spent estimating. In other words, what else could you do with the time you spend estimating?

You could use that time to estimate the value to help prioritize the team’s work.

You could use that time to identify 2-3x divergent ways of approaching the same problem, finding approaches that are cheaper or that can be tried if the first approach doesn’t work.

That said, it is important for work to be roughly similar in size to abandon estimates, which takes time as a team gets familiar with each other. And it’s still important for team members to have a way to identify work that is too big, too ambiguous, etc - perhaps a hand signal that any team member can quickly throw - similar to planning poker. Therefore, for a new team, estimating might make a lot of sense. As the team matures, abandoning estimates may also make a lot of sense, using that time for more valuable things.

#25

There’s a quick read about creating multiple user stories for each experiment at http://www.howtotrainaproductmanager.com/how-to-set-your-team-up-for-failure/. Interesting way of thinking to generate more approaches and make room for failure / pivoting.

#26

This is very similar as to what we are doing as trying to move away from time estimation. We use also 1, 3, 5 but also 8. The point basically translate directly to complexity as simple, medium, complex and finally highly conplex. I like to have the possibility to Give an 8 as they have been actually a really good discussion opener for us. It often end up telling that either the story is too big or the story is not clear.

#27

We use a question mark for the same purpose as your eight. It is too big/complex it gets split again or marked as not ready. It works for us.

#28

Can honestly say that we are nor guite there yet. The team still finds it at times hard to break them down and want to take the stories to the sprint even when they know that they might not be able to complete them. But this a learning process and we will get there :nerd_face:

#29

I’m curious, @Erah_13

How visible is the “not completing them” part?
E.g, end of iteration tracking over time of: Committed vs delivered…
In sprint Burndowns…

Does the team care about incomplete stories?
Are there many? (i.e, lots started, little finished, or many finished, and only one not finsihed…)
Do they need better / more story splitting tools in their kit?
Are they able to say “No” to the product owners?

#30

This is a struggle. I know we have difficulties with it. Part of the problem is the visibility.

It is hard to fix that which isn’t visible. “Completed” jobs mean little if defects arise from them for example. I’m working atm to configure Jira to capture transition points and dates so that we can exposes flow metrics to the team and things like planned/unplanned work.

I feel visibility and transparency is the key. It takes some work, but ultimately I feel the team will benefit.

#31

If you haven’t read Daniel Vacanti’s book, you’ll love it: https://www.amazon.com/Actionable-Agile-Metrics-Predictability-Introduction/dp/098643633X

JIRA + Kanban + Workflow with both in-progress and idle statuses = CFD and Control Charts, and visibility into current bottlenecks.

Guess who needs another integration environment ?!

44 PM

#32

Lol. I think you might be right.

I have that one, but Jira doesn’t naturally capture when jobs transition, you need to add hooks to grab the info. I hate the CFD in jira though when you’ve been working for a while.

One team I was working on had completed 2000 odd stories, had another 400 (yes WAY too many) in todo and we were clearing about 25-30 stories a sprint.

Guess what we couldn’t see due to the proportions? Yes you can filter. The one thing it showed clearly was a steady acceleration away from our capability to deliver.

#33

Vacanti recommends you don’t start the CFD until an issue “arrives”… so maybe to-do is to-soon?

#34

Fair. Still it is there. The average age measure is another I’ve started tracking. We are pretty constant, but I would like to see it drop.

#35

So… if you’re tweaking your workflow…

Add a status after “Create” and before “To Do” called “backlog”

Exclude the backlog status from your CFD
Build a dashboard with the average time in status for just the “backlog” state.
Voila?

#36

As background information. The project has been ongoing for a while and me and part of the team joined it as it moved to second phase. There had been little/no structure in the first phase so we shaped how we should be working together and the team is still in the process of getting to know each other so it was expected that there will be some growing pains.

  1. It is visible. And it is discussed in an open matter. It is best seen in committed/delivered where stories are not started at all during the sprint.

Part of this is that the team has agreed on stories with technical dependancies from another teams work and can’t actually start on them during the sprint. For this we are makeing sure that there is now dialogue between the teams.

Another part is that the team is still learning how much they can deliver in a sprint. Too eager to fill the bucket during planning.

  1. Yes. The team needs tools in splitting the stories, but there is also work to be done on how they are defined. We are grooming the stories to first make them more clear and also to split them. Introducing acceptance criteria has helped alot in clarifying them.

  2. The team is able to say no quite well to the PO, but they should just utilize this more. We had a discussion about this for our next planning with everyone.

We have a good envireoment but with a mix of different level of experiences and some bad habbits from how the project has been structured before it eill take a few sprints to learn to work together.

#37

so… @Erah_13 it seems you’re on a good track… open honest exploration

A few more thoughts:

  • A really good “Definition of Ready” might be useful - where “all external dependencies” are known
  • A set of team agreements, and/or clarity around team values
  • Reducing the size of the bucket. Target a little below the rolling average of the last 3-5 iterations ‘delivered’ stories. Some say throw out the high and the low as well.
  • Keep having innovative retros that produce “hey, why don’t we try ____ next”

Happy to fill in more details if you’d like

#38

My two cents on this topic:

  • I avoid esitmating work/tasks in hours at the individual level, it tends to be low value and leads to many agile anti-patterns (scrutinizing individual contribution)
  • If your organization has a strong interest in projecting timetables (most organizations fall here, right?)… then story point estimation on a backlog divided into sprint/release is the baseline for enabling a fairly-accurate “when will it be done” date.
    • I favor the fibonacci sequence for estimation assignment… and then after 21, I prefer 30, 50, 100, 500, 1000
    • not sure, scared of a wild idea?.. slap a 1000 on it to say “no fucking clue” and force more time to dig into it as it will blow out your projections until managed
  • using the estimates to drive discussions of whether to pursue something now vs. later can be very helpful (will it delay the release in a way that we can’t handle?)
  • another thing I try to do is mine stories from the last 6 months and lump them into groups of like sized buckets and add it to a wiki page. When the team is SWAG estimating (beginning of a release?) we keep that page up and people will “like comparison” estimate off that list which keeps speed in the process (low cost, high value) and removes some error (you always say 8, but these things are always play out to a 21).

BUT, if you are lucky to be working in an environment where almost all work is similar sized (after 6 months of estimating, we’ve learned that almost everything is a 5)… then you could skip estimation and just project based on “units of work”. I’ve only seen that be possible on REALLY stable (resources don’t rotate) and mature (been doing agile for a bit) teams.

#39

Good stuff ^

possible on REALLY stable [teams]

My world view was dramatically expanded when I started to dive into to Heidi Helfand’ Dynamic Reteaming work…

Stable Teams were always a goal of mine. No longer. “Change happens, why not get good at it”

http://podcast.agileuprising.com/dynamic-reteaming-the-art-and-wisdom-of-changing-teams/

A high level of maturity might be a prerequisite… not sure yet.

#40

A) empowering a team means to make them responsible for what they are doing, not just to be nice to them
B) incomplete stories violate my understanding from having a shipable increment of a product, which must be a superior objective of every agile approach (otherwise it is chaos)
C) an increment (Sprint) is done if it fulfills a certain understanding of “done”, and not because the time is up
D) teams can flag impediments and are committed to adapt their work in progress (they pull tasks!) according to their possibilities
E) if a team misses to deliver they must continue or discard the delivery (I always prefer to continue)
F) teams must feel bad about misses, learn from them, and improve, so it is not going to happen anymore (get back to A))

Making this understanding transparent to a team and being strict in execution resulted in superb results with teams I have been working so far. The teams become extremely happy about having a full functionality deliverable at the end of each iteration. They can decide on themselves how they get there. And they have the chance to learn and improve. This gives purpose, autonomy, and mastery to them, which are the main drivers for the motivation (see Daniel Pink: Drive).

All the rest helps to be nice and have a good relation with your team, which is important to you, but not a core driver.

Incomplete Sprints - what to do?