The Rainbow Sprint Plan

Do you ever feel it’s hard to get real progress in a sprint towards the business goal? Do you feel the feedback from a iteration picks on all the details you didn’t mean to cover this sprint? Do you feel like sprint planning meetings are dragging out? Then a Rainbow Sprint Plan may be for you.

Here is an example of a Rainbow Sprint plan:

1. A customer wants cheap vacations
2. The customer signs up for daily or weekly notifications of special flight offers
3. Periodically the System checks which customers should get notifications
4. The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system
5. The System notifies customer of any matching offers via SMS
   1. Variation: The System notifies customer of any matching offers via email
6. The customer accepts the offer via SMS
7. The System books the tickets on behalf of the customer
8. The system confirms the booking by sending an SMS to the customer
9. The customer can at any point see their active offers and accepted offers on the system website
10. The customer enjoys a cheap vacation!

What you can see from this plan:

Use case overview: The plan gives a high-level picture of the next release. We can see how the work we are doing is fitting together and how it ends up satisfying a customer need. This is a requirement technique that is basically Use Cases as per Alistair Cockburn’s “Writing Effective Use Cases“. I’ve been writing use cases at this level for the last three years and found it to be a good way to understand requirements. The trick of good use cases is to stay at a the right level. In this example, each step is some interaction between the system and a user or the system and another system. How this communication is handled is something I find best to leave for an individual sprint.

Iterative completion: Each step has a color code:

• Black: The team hasn’t started looking into this
• Red: We have made something, but it’s a dummy version just to show something
• Orange: We have made something, but we expect lots of work remaining
• Yellow: We’re almost done, we’re ready to receive feedback
• Green: Development is complete, we have done reasonable verification and documentation

So the plan accepts that we revisit a feature. As we get closer to the next release, things will move further and further into the rainbow. But we can choose whether we want to get everything to orange first, or whether we will leave some things at red (or even black) while bringing other steps all the way to green.

Demonstration script: When we get to the end of the sprint and demonstrate what we’ve created, this plan gives a pretty good idea of what the demo will look like: We will sign up the customer to a dummy signup page (red), we will register some flights in another dummy page (red), trigger the actual scheduling code (orange), then we will see that an SMS is received on an actual phone (yellow). Then we will simulate an SMS response (orange), see that they system made some communication to a dummy system (red), and send “ok” back as an SMS to the customer (orange). This will focus the team around a shared vision of what to do in this sprint.

I have been thinking in terms of a Rainbow Plan in my last projects, but I’ve never used the term before. I think the plan addresses three of the most common problems that I see in Scrum implementations:

• The team doesn’t see where it’s going, because user stories are too fine grained to get the big picture. User story mapping and use cases address this, and rainbow plans put it into a sprint-context
• The team dives into technical details during sprint planning. With rainbow plans, the sprint plan becomes the demo plan which coincides with the requirements.
• The project has a purely incremental approach, where each feature should be completed in a single sprint. This means that it’s hard to keep the big picture and the product owner is forced to look for even small bugs in everything that’s done in a sprint. With rainbow plans, the team agrees on the completeness of each feature.

May you always become more goal oriented and productive in your sprints.