Page Comparison

Meeting length:

Up to 15 mins (any chat going over 30-60 secs per ticket / per person should usually be parked for those doing the chatting till after the stand up - rarely will such chat involve everyone)

Who leads:

The team lead stand up. The In pure Scrum, the Product Manager and Delivery Manager are technically meant to be silent observers - listening to how the team are making progress. Others can also be invited to attend stand ups. Again, as silent observers. In our evolved and iterated version of Scrumban, where we have moved to Product team working and want to offer more transparency on everything we do, for this Agile event the PM and DM are members of the team, and therefore active participants - especially on the tickets with their name on the cards.

The purpose is to:

1. Agree as a team at a high level how long something is going to take (yes, we’re starting to talk about “time” here, but as a range of iterations given the number of unknowns). This is for the purpose of opening a dialogue with stakeholders that need to arrange associated activities to the deploying of the work. Obviously, the initial range of iterations we come up with will have a large element of guesswork and the range is likely going to be quite wide to begin with. This process is designed to be reused to increase certainty as work progresses.

2. Mind-map the work - we often use Coggle for this - teasing out all the elements. With 3 amigos / the whole Product Team, this mindmapping is the fastest way to shed light on all aspects of the work in one go; make all the team aware of the detail and extent of all those aspects; and have an open team discussion.

3. Having an initial think about how we would vertically slice this work into user-valuable increments - MVP and beyond

4. Estimate in a range of iterations the amount of work likely involved in each slice (this may require a more granular estimation of work on each component part of the 'slice' and totalling the estimates up based on what can and cannot be carried out in parallel. Consider team availability, other work to focus on, being over ambitious and such like.

5. Come up with a ranged estimate for the next increment (MVP if you're starting, or the next Product increment otherwise), and give a supporting narrative

6. For example. A new piece of work might be estimated to take between 7 and 13 iterations, assuming confidence levels between 60% and near 100% (we can never be 100% confident!):

   1. the lower number an optimistic estimate: assuming almost the whole team works on it, barring LiveDefects, maintenance work etc. Or another way of looking at it is that this is an estimate with a 60% confidence level. [Beware that human nature means we have a natural positivity bias - please fight against this when coming up with the positive estimate]

   2. the higher number a pessimistic estimate: based on only a sub-set of the team working on it, in parallel to working on other things / the work emerging as more complex than first thought / compensating for our natural positivity biases / etc. Or another way of looking at it is that this comes with a near 100% confidence level.

7. This exercise is useful for managing expectations of stakeholders needing lead time to help plan the roll out of the Service. It can be repeated, in order to hone in on a more precise figure as we learn more and more about the work, and especially once we start working on the first ticket.

An example Coggle mindmap, for:

• teasing out the initially known complexity (there’s always emerging complexity to consider as well);

• discussing as a team;

• estimating each component element, including whether elements can be worked on in parallel, or whether there are natural dependencies;

• summing the total to get an estimate of the range of iterations we initially think it might take. Note the high levels of uncertainty at the point… 👇

High-level estimation addresses the challenge of how to effectively convey the ‘uncertainty’ when predicting effort (that stakeholders want to understanding in terms of ‘time’ so that they can plan their activities around when we think we’ll complete something) for Epics.

A way of visualising the results of what the team estimate at the end.

The team are communicating to stakeholders confidence levels of 60-100%. This example shows the team estimating between 7-13 iterations to complete the work.

If stakeholders plan for the work completing in 7 iterations, they need to be clear that they have taken on considerable risk that it won’t, or that they will only be getting the highest priority elements at that point (and the rest will follow on after that).