Notes on story walls – longer term planning

09 February

I have been writing about story walls and how agile teams might use them to manage their work. But some agile teams feel rushed because although they can see what needs doing today, they don’t know what is coming next.

So in this article, I will extend the idea of using a story wall to look into the future.

Photo of a task wall

 

A release plan

The most common approach to extending the story wall in agile teams is to add a release roadmap or release plan.

Here is a typical example. The team has a story wall this sprint. Now they add a second wall with the work coming up for the next few sprints.

Photo of a release plan

This is not a guarantee, but it can help planning. Each sprint they can update this wall to show the features they will get to next.

For the current sprint, many teams record their current defects and maybe their definition of “done.” In a similar way, some teams put their longer term targets for growth, performance, quality etc.

This wall gives the team and their stakeholders an idea of where the team is headed.

 

Dependencies and inch pebbles

Some teams are tracking their own work well, but constantly finding that they are waiting for other teams to do something, or that they are surprised by what another team did.

The teams often have a “scrum of scrums” to overcome this. A scrum of scrums is where someone from each team turns up for a 15-minute meeting each day. Everyone in the meeting gives the headline for what is happening in their team and whether they need something from another team.

The daily meeting works well. But it works best if it is focused on the here and now. If it starts to focus partly on now and partly on future planning then it turns into an hour-long gossip session which sucks time from people’s lives and makes them quite sad.

So teams separate the daily work from the future work.

In addition to the daily meeting, they get together once a week and have a “dependency battle meeting.”

But not everyone from the team needs to go. Rather, Someone from each team (not necessarily the boss) goes along.

Each team has its own release plan and we don’t want to go through that in this meeting. Rather people share the crucial things that are coming up in the next (say) 6 weeks.

Photo of a dependencies and inch pebbles chart

In our picture, the teams are up to week 16 in their long journey. The “good” team might now tell everyone that they are having a giant DR test and data festival in week 19. They will then all be heading off to the awesome data conference.

They add two index cards to week 19.

But then the “ugly” team remind the good team that they need a data feed from them in week 19 and that they will also need some of their team for the testing of their new gadget.

The rep from the good team explains that this won’t happen now and suggests that the ugly team change their plans and then relax.

The ugly team members do not seem so relaxed and a discussion follows.

I have found that this meeting, with a visible reminder of the dependencies between teams, makes life a lot easier on complex projects. I have had up to 20 teams represented in a room for a weekly meeting and it actually worked really well, even at that scale.

In my diagram, I also included “inch pebbles.” This is a term I took from a great book by Johanna Rothman – “Manage IT”.

A lot of teams talk about milestones. But Johanna suggested that rather than talking about giant stones that are a mile apart, they plan by looking at small pebbles that are an inch apart. I liked the term so I use it.

The point is that teams share not just their dependencies but the headlines and goals they are aiming for.

For example, the representative from the good team shares their plan to do performance testing in week 19 and the bad team leader shares that they really need a particular feature in week 18 for the big trade show. The ugly team now understand the priority of the things these teams are asking for, and get a good feeling for how the other teams are travelling.

 

180-day planning horizon

Some teams, particularly operational teams, don’t have sprints or iterations. Instead, they are constantly working and planning.

But these teams often still have a rhythm (eg budgets are due in 6 weeks, We want to go the college hiring session in a couple of months).

These teams might use a 30/90/180 day plan, or something similar:

Photo of a horizon planning chart

Each team has a monthly meeting to break work down. They add large goals to the 180 day column if applicable (these might be “epics” in agile – or key goals if they are an accounting team). They also confirm that the ones that are listed are still correct.

These 180 day goals can be performance targets (achieve 500 customers, retire the mainframe) or they can be events (Move to new office, run DR test).

Next, the team breaks down 180-day targets into anything that has to happen in the next 90 days if they are to stay on track. They also add anything else that should be there.

Normally they also have a heart attack and panic, before descoping some things.

Finally, they go through what they should focus on in the next 30 days in order to get today’s things done and to start work on the 90-day items. The things listed here are smaller and more numerous that the 90-day and 180-day targets.

Teams can then prioritise the 30 day work into “next sprint” and “other work” in the sprint planning meeting and add the “next sprint” items to their story wall.

This is a visible way to manage a backlog and forces you to store less information because it just won’t fit on your wall.

You can make this more robust and more formal by adopting an evolving balanced scorecard or strategy map approach. This also takes more effort though.

 

A simple roadmap

I was in a team whose stakeholders attended trade shows, for which they wanted extra support from us, and the wanted cool features to talk about.

We kept being surprised by these trade shows, with someone asking for our help “next week on Tuesday to Thursday.”

It was messing with our rhythm so I went to speak to the marketing guy. He was surprised that we were surprised.

“It’s not like these things come out of nowhere,” he said, “We have a calendar of when the trade shows will be on for the next 12 months. How could you not see them coming.”

We didn’t see them coming because we didn’t see the calendar. We thought his “insane” crew just appeared at random to make our lives difficult. But they thought we were constantly unprepared and ignorant.

There is a lot happening in your organization and it will often not be helpful to have a giant calendar with everything on it. But you can have a simplified calendar (or “roadmap”) that shows the things that impact you.

It might include the rollout dates for big projects that will impact you, holidays where you and your clients won’t be around, when the finance crew will be unavailable etc. It might look something like this:

Photo of a road map

 

A “utopia” roadmap

I am not sure what this next one is called. But I have often found that IT architects use it and I find it really useful.

Here we combine a roadmap with a long-term dependency battle map.

Photo of a utopia road map

On the bottom left, we have today. On the top right, we have Utopia (or our long-term future state).

But we won’t go from here to utopia in one quick move. So we draw lines to break the page into multiple horizons – for example, 3 months time, 6 months, 2 years and final state. Usually, these lines go from the top of the page to the right of the page.

Then we split the diagram based on teams, technologies or components of our solution.

So, for example, in our first time period, we might have excel as our reporting tool. This might stay as our reporting tool next time period and the one after and then disappear. The infrastructure might be mixed windows 3.1 and apple “something”. But soon we are going to be windows 10.

This diagram helps to see why we need to do something to align with others, or why things are going to get messy if we launch the new CRM system before we change our reporting tool.

 

Make your own up

These are some of the simple walls I have seen people use. The common theme is that they make life easier for the team by helping them see what will soon appear over the horizon.

They can all be more effort than they are worth, or they can be really useful.

But this is not the list of “best-practice” walls. You can make your own up and use them as you see fit.

 

Posted by James King
Copyright © James King 

Thank you!

Your details have been submitted and we will be in touch.

CHAT
CALL