Agile planning: the basics explained

Written by , in category Agile & Scrum

14 December 2012

There are different ways to build a planning that actually embraces change. The most basic requirements are that this planning is easy to use, fast to change and makes it easy for you to visualize impact of change. It should give you just the necessary amount of information to make decisions about change well founded and fast. Whether you are using story points for your estimates in a more scrum like approach or you have a kanban system with classes of service, you can use the same graph to help you visualize your mid to long term planning.

In a kanban system you would still have to measure the amount of work items of each type you produce over a certain period of time, very similar to the concept of velocity (amount of work finished during a certain fixed amount of time, like a week) that we know from the scrum framework. This graph is called a burnup chart, mostly because the human mind likes things to go up in the longer term. When we talk about short term goals we prefer a burndown, like the sprint burndown in scrum. In this chart we plot out the finished amount of story points or work items on the Y axis and time on the X axis. This is a very simple yet powerful visualization of what amount of work you estimate to be able to finish by what time.

What is so powerful about this graph?

If you want to change priority of some work items or you need / want to bring in some new ones, you can immediately visualize the impact it will have on all the other work items. It will also show you the prediction on which items will actually not be ready for the next release. Using this impact analysis data will make it easier for you to decide if this change is ok or not. This example shows only 1 line, this means that every work item has 1 estimated completion time. Since we prefer to work with ranges rather than absolute estimates, we could use the concepts of lower and upper control limits, which we know from the kanban variation report charts, to declare a range for our velocity. If the chart below is the variation chart of our velocity, we could determine that our lower control limit is 24 and upper control limit is 30.

Using this range we could plot out these two control limits over time, instead of using just one number. We would end up with a graph like the one below.

If we need to make a planning we can now use a best case – worst case scenario approach. All the things underneath the blue line will be surely finished by the given time. Everything in between the two lines has a high chance (if you look at the variation chart on the previous page, we could conclude about 85%) of being ready while everything above the red line is highly unlikely to be done by a certain time.

So this practically boils down to how much risk you want to take in your promises. If you feel lucky (punk) you can promise 300 story points (or work items) to be finished in 10 weeks. If you want to play it safe you can promise 240. Everything in between is possible and will have a certain amount of risk involved.

The reCAPTCHA verification period has expired. Please reload the page.

Never miss an article again!

Relevant information about Agile and scrum by the best
Updates on our amazing public events
Max 2 times per month