A graphical representation of agile team ceremonies.

I recently had some fun creating these graphics with Shelley Beeston. All of them might not apply perfectly to you, your team or project, but perhaps they’ll work as a useful starting point.

We’ll cover the concept/purpose for:

• Release planning
• Iteration planning
• Iteration kickoff
• Iteration management
• Standup
• Story review
• Story kickoff
• Showcase
• Retro

Context on story-cards

We’re going to refer to quite a few stages in the story-card life-cycle. To get context around story-cards and the steps to create them, you should checkout Nanchu’s infographic on xd/ba workflow and how story-cards are created.

Release planning

Every 6-8 weeks of a project, stakeholders and product owners get together to revisit/discuss the big picture of the project. The group does some product visioning, creates some high-level user-journies, and perhaps some wireframing and epic writing around feature-sets.

The release plan on the right depicts 5-iterations within a release and the features/epics desired in each iteration. Note that this is a roadmap to help shape iteration planning. Your release plan shouldn’t be overly detailed or perscriptive. The point to give some direction to the delivery team.

Bad smells in release planning

• All necessary stakeholders are not involved. If you don’t have commitment, you don’t have a product.
• Sessions are not planned with enough time to get all the right people. The full-list of stakeholders often means busy schedules. Get it done early.
• Direction not clear. Stakeholders can’t agree on a high-level vision? Time to step back and re-evaluate.
• Detailing too much up front. This is not the time to make iteration-level story-cards. This is a time to create high-level feature-sets, epics, and purpose. Define the ‘What’ not the ‘How’.

Iteration planning

On the table, we see the set stories that the team is considering to play during the up-coming iteration. Around the table are the appropriate team members and the types of questions they are asking.

At this point story-cards are ‘ready for dev’ (e.g. the feature has been value tested, have acceptance criterea and wires to visually express the layout/functionality). Note that the definition of ‘ready for dev’ will vary from team to team.

Business analyst

The Ba (or baxd) will direct/facilitate the planning session. As the quarterback (halfback for rugby fans) of the story-cards, the Ba can answer questions around what the story is and provide context to the why we’re playing this story for the current iteration. E.g. Perhaps the story is a dependency of a larger epic and needs to be played now in order to get proper in-app usability-testing prior to implmenting the larger-feature. As tradeoffs surface, the Ba will manage the tradeoffs that need to be made between product/design/development in order to implement a feature within the release.

We want to play this story in this iteration because… -Ba

Product owner

The Po (Product owner) is making tradeoffs between stories. Sometimes scope is just too large

If I have to choose between Story-A and Story-B, then I would rather have Story-A. My rationale for this is… -Po

Xd, Dev and Qa

Though Xd, Dev and Qa’s questions are different, they are looking for a similar pitfall in planning: story dependencies (e.g. Playing a ‘forgot password’ story isn’t very useful, technically feasible or testable if a user isn’t yet able to register).

Does these stories add up to something usable? -Xd

Is this a logical play order? -Dev

Are these stories testable? -Qa

Iteration manager

The Im (iteration manager) is looking at the estimates and current velocity of the team to see if the work load seems like a reasonable amount for the iteration.

Is this realistic for our current velocity? -Im

Bad smells in iteration planning

• All role representation are not present.
• No clear view of all work.
• Assumptions around story have not been validated.
• Team capacity not known.
• Features not developed by priority.
• Not collaborative.
• Ignore uncertainty.

Iteration kickoff

Iteration kickoff is a quick chat for the entire team that is held at the beginning of an iteration to go over what was decided upon during iteration planning. This shouldn’t take any longer than 10-minutes. The goal is to ensure that the entire team is now on the same page and understands what they’re trying to accomplish within the time period.

Bad smells in iteration kickoff

• All necessary team members are not present.
• Too much out of scope discussion.
• Too much discussion about future scope.
• Story representations not ready/clear.

Iteration management

Iteration management is an ongoing checkin between the Im (iteration manager) and Pm (Project manager) where they discuss velocity, scope management, raise any issues/blockers that may impact the team’s ability to deliver.

Bad smells in iteration mangement

• Multitasking – Across multiple projects, across multiple tasks (Starting multiple tasks before completing others).
• Blockers not clearly shown or addressed.
• Non critical changes occur during iteration.
• Bottlenecks not addressed by team.
• Distractions other than critical issues occur.
• Too much/unknown other work.
• Unfocused discussions not about intent of discussion.
• Stories in progress the whole iteration until the end, none delivered throughout.
• Trade offs are not made between scope, time, resources and costs.

Standup

Standup is a quick, full team, daily chat where everyone hears updates about current progress and what is planned for the next 24-hours. This shouldn’t last more than 10-minutes. If they are going over 10-minutes, try making everyone wall-sit until standup is over; I promise that your standups won’t very long.

Bad smells in standup

• Reporting to the leader. Updates are given to the entire group.
• Low energy. If people aren’t interested in updating others, find out why.
• Attendees absent, late, or meeting starts late. Maybe standup is at the wrong time? Perhaps it’s worth changing from morning to afternoon.
• Socializing. This is a time for quick updates on work.
• Story-telling. In-depth updates should be reserved for huddles. e.g. talking deeply about typefaces that work/don’t work OR the trial and error of deploying yesterday.
• Problem solving. Same as above.
• Obstacles not raised or removed. Does your team have a blocker? Now was the time to mention it. Why doesn’t your team feel comfortable identifying blockers during standup? Get to that root cause.
• “I can’t remember” or “Not sure what I’m doing” or ‘Nearly Done”. This doesn’t mean anything to a team. You’ve got 140-characters; use them.
• Referring to numbers rather than features. If you’re talking about stories as numbers, then you’re not focussed on the product or what you’re building.

Story Review

Story review is a step in the AnD (analysis and design) process where Devs and Qas can poke holes in the stories and add insight into the areas that have not yet been addressed.

Bad smells in story review

• All necessary stakeholders are not present.
• Intent of story is not clear.
• Participation in the story review is minimal.
• Too much out of scope discussion.
• Too much discussion about future scope.
• Visual representations not ready/clear.

Story Kickoff

This is an adhoc, less-than-10-min chat that happens when a pair of Devs pickup a story. The pair grabs a Ba, Xd, Po and Qa and they go over the story. The point of this chat is to make sure that everyone is on the same page. Yes, again.

Why check again? 2-reaons:

1. Because context-switching is tough
2. In a fast-paced software team, the story may need some tweaking. E.g. In the past 24-hours, your product’s usage-analytics may have identified something that would require a small-implementation tweak to the story.

Bad smells in story kickoff

• Starting work without clear and agreed definitions. Maybe the story needs a rewrite or more AnD.
• Assumptions around story have not been validated.
• No dedicated team member to see the story through.
• Not right people involved.

Showcase

At the end of each iteration, the delivery team gets to show stakeholders (or just a wider audience) what the team has accomplished. Here we focus on outcome, not output. That means you’ll be showcasing working software; nothing more, nothing less. The point is to truly understand the definition of ‘Done’.

This helps the team to manage the expectations of their stakeholders. No longer are they being given comps and waiting to see something mind-blowing. They are there to see something good, solid and deployed; a functioning application.

Stakeholders can now engage and ask questions of the team. Perhaps they don’t understand why something was implemented now vs later. That question can be concisely answered by the team. These questions may also help to drive prioritization for the next iteration - though be sure to manage stakeholder-expectations around how/when the team will be able to address their questions/ideas/concerns.

Stakeholder questions may also lead the team to address challenges they faced when implementing particular features/stories. Perhaps heavy signoff business-processes prevented a story from being completed. Maybe the Xd team needs the ability to do value or usability testing on real-users in a retail-store, but the business couldn’t remove that blocker in time.

Bad smells in showcase

• Always the same person presenting.
• All necessary stakeholders are not present.
• Participation in the iteration review is minimal.
• Too much out of scope discussion.
• Too much discussion about future scope.
• Little time to prepare.
• Expectations around feedback not clear.
• Stakeholders are surprised with what is being reviewed.

Retro

Each iteration, usually following the showcase, the team will get together to reflect on the past iteration. At ThoughtWorks, we practice retros in 3-parts:

1. Health check
2. Prompts
3. Action items

Health check

You want to provide the team with a safe environment to collectively identify and fix problems. People will only chat about problems in a comfortable environment. So, to make sure your team will get value out of a retro, do a health-check.

Each member of the team writes a 1, 2, 3, 4 or 5 on a sticky-note. Then folds and passes them to the front. The stickies are then posted on the board.

Prompts

• “What went well?”
• “What needs improvment?”
• “Questions”

Group the stickies together when you can, this will make it easier to discuss them. If the team is on the same page, you’ll often be able to find clusters of similar stickies.

You will often be in a time-box, so it helps to do a time-check and then figure out how many specific questions you can address. When that number in mind, have the group dot-vote on which items they would like to dicuss.

Action items

From the team’s discussion around improvments / questions, write down the action items and assign them to the appropriate champion. Make it clear that it’ll take a team to handle improvements and it is not on a single individual to hold up the for an entire team.

Bad smells in retro

• Too much focus on what went wrong.
• Language is negative and blaming.
• Items are too vague.
• Conflict occurs.
• Similar items come up.
• Meeting gets off track, over runs.
• 1-person assigned to many action items.

The big picture

Collectively, these don’t really fit into a single time-table. I’m thinking about how to display them as a large, collective view. Any ideas? Already seen it done well somehwere else? Tweet @matthewcopeland.