The "How would you spend £1000" prioritisation exercise

We did a 3-hour session the other day to come up with requirements for a open tender procurement, with a large group of stakeholders from around the organisation. Each stakeholder was coming from a very different angle on the problem, and the challenge was how to arrive at a set of commonly agreed requirements in priority order, with some idea of how they would be scored in the tender process.

The exercise we ended up doing was actually pretty fun and a good way to lighten up a long session.

Here's what we did:

1. Before the session, collect some play money (either from a board game or create your own) in a number of denominations
2. Once all of the requirements are written on index cards, lay the cards on the table
3. Give each participant their "budget" (in this case, our budget was £1000, divided into £200, £100, £50 and £20 notes)
4. Get everyone to "spend" their money on the requirements, piling their money on top of the index cards
5. Send the group on a coffee break and tally up the piles of money on each card
6. Arrange cards in descending order of money spent on them.

By the end, we arrived at a linear priority list of requirements. Some were surprised by which requirements floated to the top, which generated useful discussion and thoughts on how we can expand the sub-criteria for those categories.

How do you do your priorisation exercises in a large group workshop?

Improvement Experiments Kanban

The team are very keen to always improve their agile practices, with many suggestions coming out of each sprint retrospective. Some of these get implemented, stick, and become part of the new way of doing things. Others fall by the wayside and are forgotten.

Improvements can be things like:

• Implement pre-dev checks to explain the work that will be done
• Rotate the scrum master role around the team to keep it fresh and ensure everyone is involved
• Create a Readiness Board to ensure stories are prepared enough to go into a sprint

We had a few excellent sessions with Matt Wynne and his colleague Rob last week, where they helped us to focus our improvements.

The Kanban board is courtesy of Agility in Mind, and was re-purposed to become an Improvement Experiments board for the team.

The idea behind the Improvements Experiments is that, rather than just a collection of "good things we should be doing", some structure gets added to the process improvement.

Here's the process in a nutshell from Matt & co:



We've already started tracking items on the board, and so far have proven 3 experiments. So it seems that we're onto something here!

Have you had any success with methods of tracking the improvements your Agile team suggests during the sprint retrospective? Please comment and share your experience.

Translating roadmap items to actual stories

We have found that sprint planning sessions go a whole lot quicker when we know the details of the stories ahead of time, including having architecture discussions and working out any dependencies on other teams well in advance. I can't tell you how many sprint planning sessions have been side-tracked by lengthy discussions about architecture, coding approaches or why the piece of work is more complex than anyone originally thought. Our sprint planning sessions could take 4 hours in the bad old days, even when we tried to timebox our discussions.


Planning ahead without the team

Here's how our process used to work:

1. “Next Sprint Goals and Roadmap”
   Who: Product Manager and Project Manager
   What: Establish the next sprint goal, list the epics in priority order and plan the epics for 3 iterations in the future (headlines only, no detail in the epics)
2. “Pre-sprint Backlog Pruning”
   Who: Product Manager, Project Manager, Lead Developer & Senior SE
   What:
   
   • Review next sprint goals
   • Review epics in priority order with a view to breaking them down in advance of sprint planning
   • Take a realistic look at what’s achievable in the sprint.   
3. “Sprint planning”
   Who: Entire team
   What:
   
   
   • Features are explained by Product Manager
   • Team commits to a number of points based on the velocity of the previous sprint, plus any upcoming training/absences.
   • Tickets are pre-prepared using templates to include Definition of Done, NFRs, Tests, etc.
   • Priority of tasks is reviewed again with Product Mgr.
   • Tasks are pointed and anything over the threshold is moved to the top of the Backlog
   • Release tickets and load testing tickets are raised.
   • Cards are printed out for the wall.   
     

What's missing?
 

In the weekly "Next Sprint Goals and Roadmap" session, the Product Owner and Project Manager worked out a roadmap detailing several month's worth of planned work and put it all up on a board in plain sight of the team. The thinking was that they could get on with the forward planning without having to take the team away from their work and that the team could then see the headlines that came out of the session. It felt pretty comprehensive and efficient. However, funnily enough....

 
It turns out that visibility on the wall doesn't translate to a team understanding of the upcoming work.


The team were at a loss as to how we could manage to get "on the front foot" and close the gap between high-level roadmap items and actual, broken-down-and-estimated stories.

What's missing is the team!

One of the major themes of our Sprint Retrospectives was Teamwork, and how we could achieve visibility of upcoming work. How better to do this than to involve the team earlier in the planning activities?

We gave it a try, expanding the invite to the "Pre-sprint Backlog Pruning" sessions to the entire team.

It worked a treat! Instead of the team first hearing about upcoming work as an email of headlines before sprint planning, and only getting a full explanation at the start of the actual planning session, they began to hear about the stories several days ahead and could have time to prepare tickets and think about their approach.

Now, we're working on ways to increase visibility of upcoming work even further and have introduced a Readiness Board as an experiment. 

Learning to think ahead with a "Readiness Board"

The "Readiness Board" is a Kanban-style grid on the wall which allows us to prepare features and flesh-out stories before they are accepted into a sprint.

Features come onto the board as high-level titles like "Build an admin app",  and leave the board as a piece of work that’s understood by the whole team, story pointed, with Technical Architect's sign-off, and with an idea of how the feature could be demo’d. A Work-in-Progress limitation of 2 stories helps us focus.

The benefit to this process is that our backlog pruning and sprint planning sessions go faster and more smoothly because the uncertainty has been removed from the stories and the technical approach is already agreed by the time the story reaches the sprint.

Each feature has a checklist on the card to indicate that the DEFINITION OF READY has been fulfilled.