To estimate or Not to estimate

#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?
#41

I wish these conversations allowed sub-threading as I’m having trouble tying @hdietrich A-F list as responses back to points above…

@andycleff- sub-threading on the backlog? :wink:

#42

You are right that this thread is becoming confusing. Sorry!

Probably we should setup new threads as follow ups on the topics discussed in here, as they are not related to the initial topic anymore.

#43

Adding the external dependencies to the definition of ready. Now why didn’t I think about that before. Thanks!

#44

@Erah_13 needs more slack time.

Reflection > Reaction

:^)

#45

Probably should, but I’m loving the conversation…

#46

Indeed, it is taking us to the essentials of agile. And it is haptic, full of great examples.

Anyhow, I have forked out the topic of incomplete stories now. To be able to continue following up on several topics without getting messed up.

#47

An old post, but perhaps apropos to the topic of estimating…

tldr: we suck at estimates