Planning: the green and amber list

When doing scrum planning, trying to figure out what can be achieved in a sprint, there’s always variation. Especially in projects where you can’t rely on what came before. You can use yesterday’s weather, and break down tasks, but if you can’t estimate more accurately than “between a day and two weeks”, and you can’t use Kanban, and you have a big enough team, one factor I’ve found useful is to create two backlogs for the sprint. 

In the green list is all the things you know you can complete, and are the most important. The amber list is what you know you can start but can’t guarantee to finish. These might be bigger, exploratory, spiking tasks, or smaller, less important ones that can be done by the developer who finishes the spiking tasks towards the lower end of the estimates. 

Mostly these tasks are the highest priority for the following sprint and will move to the green list, but occasionally they will be smaller tasks that can roll over to the next amber list – such as a task you want a particular developer to handle as a quick win in a new area of code. Importantly, they are never blocked and always ready to start at any point in the sprint.

How do you deal with minimum and maximum caps for scope when planning? 

5 replies on “Planning: the green and amber list”

There are always tradeoffs, so the following is not a “you should do this”, but rather a “it has worked very well for some of the teams I have engaged with”…

The smaller the breakdown the easier it tends to be to estimate. More importantly the number of items increases. Lets pick some semi random numbers.

Team has story pointed a number of PBI’s and based on their velocity and the PO’s priority is considering the top 8 for inclusion into the sprint commitment.

If each PBI is broken into only 1-2 tasks, then there will be 8-16 tasks [so we will use the mean of 12].

If each PBI is broken into 8-10 tasks, then there will be 64-80 tasks [so we will use the mean of 72].

In the latter case if a given task takes a significantly different amount of time than estimated it will have less of an impact. There is also a good chance that other tasks will counterbalance that one task leading to a net result that can be very close to the original estimate even when the individual items vary wildly.

I do like the “green” / “amber” as a characterization mechanism and a planning tool, but my instinct is that two distinct backlogs can make certain elements more difficult to track.

Liked by 1 person

Any advice that states “you should” rather than “I tried” is bad. At its heart, agile is the application of the scientific method. Do an experiment. If the hypothesis works for you, keep doing it, otherwise test a new hypothesis.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.