I joined an already established team, that had been working on a large scale Enterprise Data Warehouse implementation for over a year. I logged into Mingle and started to get up to speed with available planning data. My first step was to produce a burn-up chart to see how predictable the team were but also to check stakeholder expectations were aligned. Here’s the first burn-up:
This graph was unable to answer the question “when will we be finished”. The backlog is constantly growing over time but even worse, the orange line (total scope) and the green line (work done) are diverging. This makes forecasting extremely difficult resulting in a more deterministic approach (plan and promise) rather than an empirical approach (measure and predict).
The reason for the constant growth in scope was down to the way the work was cut. The team had defined all the high level epics. Each sprint they would select an epic from the backlog and break it down just-in-time for the next sprint(s). This is a very lean approach as it minimises waste by not committing too much time to up front activity where requirements are highly volatile. From a forecasting perspective this is extremely bad. Not knowing the total scope prevents us from extending the planning horizon beyond the next couple of sprints. It’s a trade-off between upfront effort and longer term planning.
We were about half way through the EDW implementation when I joined the team so we had lots of known data points. I needed to extend the planning horizon without distracting the team away from delivery with wasteful estimation activities. If the team attempt to breakdown all the remaining epics into stories and size them at this point then it could take them weeks. Weeks of wasteful effort. Enter the epic sizing ruler.
I first came across the concept of an epic sizing ruler at one of my client sites. Visually it looked good, served a really useful purpose for helping with prioritisation, and established a very rough order of magnitude. Maybe it even served to encourage the team to break the epics down to reduce batch size. Here’s a photo of their epic sizing ruler:
For us we had already delivered a number of epics so we knew how many stories each epic translated in to. I took the epics that had already been completed and stuck them all up on the wall. I wrote the number of stories in the top right of each card then distributed them across the scale Small, Medium, Large, eXtra Large, and eXtra eXtra Large. We had some minor debate about what number of stories constitutes what sizes but we all settled on the groupings below which ‘felt’ about right. Note the purposeful lack of science here! Once the ruler was set up we moved on to actually using it to size epics.
To use the ruler we simply took all the remaining un-sized epics in the backlog and relatively sized them by pinning them to the board in the place that felt about right. It took the team less than an hour to relatively size 23 epics.
From this relative sizing exercise we assigned an arbitrary default number of stories to each size based on sizing we observed from the historical epic sizes on the ruler:
- S = 20 cards
- M = 30 cards
- L = 50 cards
- XL = 100 cards
- XXL = 200 cards
The next step is to create placeholder stories in Mingle against each epic that provides the data to enable more accurate forecasting. You can see from the burn-up chart below that the scope and done lines are now converging, thus extending the planning horizon.
The team haven’t changed their process in regards to just-in-time breaking down of epics either. They still do this but what they now do is simply replace the placeholder stories with real stories as they breakdown the epic. Sometimes they end up with a couple of placeholder cards left over that they simply delete. Sometimes they don’t have enough placeholder stories to replace so they simply create new stories. So far we’ve found the sizing to be pretty accurate having now broken down many epics.
One concern we had was the number of placeholder stories might influence how the epics are broken down, i.e. to make them fit. But to counter this all stories are relatively sized as part of the standard approach to story writing. The team always aim to write the stories so they can get across our value stream in 5 days or less. Anything bigger than this they attempt to breakdown the story further.
In summary, visualise your uncertainty, use known data points where available, use burn-up charts to forecast and extend your planning horizon.
