Purpose of each Agile event

What is the purpose of planning?

1. Identify goal(s) and what needs to be done and ID specific stories against the goal(s)

2. Planning tickets to bring into Ready for Dev to work on (most of which to complete) in next iteration.

3. Ditto above, plus check the capacity of the team in the next two weeks (availability etc)

4. Resolve prioritisation / sequencing

5. Assessing work in progress on the board against refreshed goals

6. Planning is not a refinement session - this is what the Refinement session 2 days before is about

Meeting length:

Up to 4 hours (with comfort break recommended!)

Who leads:

The team lead Planning (usually facilitated by the Delivery Manager). The Product Manager should be there to outline the Product Goal and for the team to ask questions of, if required.

Others can be invited to attend Planning to answer any clarifications the team might have - e.g. stakeholders for the iteration goal - but such clarifications will normally have been teased out as part of refining the tickets

• discuss status of tickets on the board;

• what have you done to move them on

• who has been involved in helping out (are we pairing / pair programming on any tickets - any learning for the rest of the team to benefit from?)

• any issues you’ve uncovered (has this altered the size of the ticket - does it need a chat outside stand up to address this, if so)

• any help needed (to avoid the ticket becoming a blocker in the column).

• clarify to each other what you’re currently working on (yesterday / today),

• highlight where there is a need / opportunity to overlap / collaborate with a colleague, and

• highlight where you have uncovered any impediments (anything getting in your way that a colleague, or a Delivery Manager can help remove).

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. 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.

Some teams call this event a “Show and tell”. And we do “Show” and “Tell” what we’ve done (cross reference Definition(s) of Done. But that’s only part of what this event is for… The 3 pillars of Scrum are Transparency, Inspection and Adaptation. Showing and telling only addresses the first of those pillars.

It’s called a “Review” because it is primarily an opportunity for the team to invite stakeholders to give the team their feedback on the work that the team has done in the iteration and their plans for the coming one. This is the Inspection aspect.

It is designed to be a highly engaging session, full of two-way communication. And it is meant to be transparent - highlighting any problems encountered and how those problems were handled and how the team has tried to mitigate them happening again.

It is not designed to be a one-way, ‘Here’s what we’ve done' status report. Any Review that feels more like this kind of an event is an indication that the team think that they have all the answers (lack of intellectual humility), and that stakeholder feedback and advice is irrelevant (not embodying User-Centred Design). A true Agile anti-pattern.

This helps with:

• getting internal understanding of work completed (transparency);

• getting wider support for any impediments the Delivery Manager was unable to remove (transparency and inspection).

• managing the expectations of stakeholders (transparency and adaptation);

• getting advice on future prioritisation and direction based on the work completed (adaptation);

• getting group feedback to inform future decisions (adaptation);

• showing stakeholders the iterative nature of Agile team working - they give feedback in one Review, and they can often see the team act on that feedback in the next, or shortly afterwards (adaptation).

Meeting length:

Up to 2 hours (plenty of time to really discuss things with stakeholders).

Anything less than an hour indicates either a lack of focus on feedback; or taking on tickets that were too large to finish in two weeks.

Who leads:

The whole team lead Review (i.e. Product Manager and Delivery Manager as well as the rest of the Team). The best people to talk about any of the work are the people that did the work!

Arguably the most important event in the iteration.

A core principle of Agile working (Principle #12) is that the team continuously improve (consider any or all of the following: individuals, interactions, processes, and tools): “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly“.

This is the event where the team applies Agile to the way it works as a team - like Agile Inception!

Without this meeting, rot will set into an Agile team:

• conflicts will simmer under the surface without being addressed

• lessons there to be learned from what has occurred in the iteration will go unnoticed and unaddressed

• opportunities uncovered during the iteration won’t be articulated and seized upon

• successes achieved won’t be celebrated - as human being, we need to be appreciated and this is one of the key events for addressing this fundamental human need.

Meeting length:

Up to 1.5 hours

Who leads:

Anyone can lead. The whole team participate in Retros. That includes Product Manager and Delivery Manager. No one outside the team is allowed to attend in order to preserve this event as a safe psychological space to constructively critique the iteration just passed.

Not an official Agile calendarised event. However it very much is an Agile activity.

We have a placeholder hour set aside a couple of days before Planning with the purpose of getting team understanding of the detail of what’s coming next - ideally related to the intended iteration goal for the next iteration. This makes the Planning session significantly more efficient. In effect, this Refinement session is a pre-Planning session - getting our ducks in a row ahead of planning the next two weeks of team effort.

Outside this calendarised Refinement session, anyone can call for a 3 amigos session anytime (generally people ask for one during a stand up). 3 amigos is a loose term to indicate a conversation between 3 or more members of the team that have different perspectives they can bring to bear on proposed work - it’s often Product, Design and Development, but for different types of work could be a combination of any specialisms.

What is included in Refinement / 3 amigos?

Here’s my checklist:

1. Does the ticket title clearly convey the user value? Ticket titles are often what our users will see, so writing them clearly in this way improves transparency

2. Is there a well-formed User Story? Explaining who it’s for, what it is and why it’s needed

3. Are there good Acceptance Criteria? Essentially determining how we can know that the work is Done. It should be possible to turn ACs into automated tests.

4. Is the work estimated: Value and Effort?

5. Where appropriate are there sub-tasks that help to indicate where team collaboration could be achieved?

6. Finally, do all the amigos / team feel confident picking the ticket up and coordinating the work on it (not doing all the work themselves)

Meeting length:

Up to 1 hour

Who leads:

Anyone can lead. Product Managers and Business Analysts in particular are extremely useful to have involved in these sessions. The whole team participate in Refinements. Stakeholders / Subject Matter Experts can also be invited to help clarify details.

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).

Meeting length:

Up to 1 hour

Who leads:

Anyone can lead. Product Managers and Delivery Managers can be good, but due to the often technical nature of discussions, it can be even better for a developer to scribe, with someone else coordinating the discussion.

We have two pages on Confluence already set up for these:

• Tech Sharings

• Team Sharings

If you think of anything at all to share - tech or team related consider this… do you think you’re the only one thinking it?

Assuming your answer is almost certainly “No!”, it’s probably worth doing a sharing on.

Sharings can be 5 mins, or up to an hour. If it merits a follow up, then more!

Either you’ll be helping colleagues understand something you feel you understand, or you’ll highlight where you have gaps, and give your colleagues the opportunity to help fill them.

Sharings don’t have to be presentations (PowerPoint, screen-sharing of code, whatever). They could be an agenda of discussion points and a pure discussion. They could be brainstorming of something - team knowledge on some tech / how to best use a tool, etc. Anything at all that will contribute to the concept of Team Continual Improvement.

Meeting length:

Up to 1 hour

Who leads:

Anyone can lead. Ideally record the session for anyone unable to attend on the day