Warning! The introduction to this article uses a train metaphor but has nothing to do with SAFe.
Emergency! My favourite Agile product teams have been derailed! The perfect click clack of the sprint cadence dropping of valuable software at every station has ground to a halt. The railway controller has been replaced with a new one, and he wants to know exactly which passengers will be getting on and off the trains for the next year. And no trains can run until he knows.
Oh dear! This means we need to do a huge survey of the local population and figure out who is going to get on and off at every stop. This will take a few months to complete. We do know there might be some variance, but we are expected to keep this to an absolute minimum. After all, how can we possibly run a railway if we don’t know who is getting on and off the train right until the end of the year!
For 3 weeks my favourite trains sat in the sheds. Whilst the drivers created their surveys and went around delivering them to the villages and towns. After three weeks, the head engineer has had enough. He phones the railway coach consultant, “Surely there has to be a better way! It was all going so well!”.
Well, there is, but we need to talk to the controller first. A meeting is set up and the head railway big cheese boss exec head controller c-level person has 30 minutes in his schedule to give to us.
All the railway managers are there, and the controller asks what the problem is, and why should he listen to us? Well 30 minutes later and a lot of discussion about complex adaptive problems, time to market, adaptability, feedback cycles, and just plain getting on with it, we have an agreement to plan out the 2016 roadmap using an Agile approach. We will see how it goes…
Well, the pressure is on in one sense, and off in another. We don’t have to do the lengthy survey of all customers, but how can we know enough to run the railway?
We gathered the scrum master, a few engineers, the product owner into a room. Provided good refreshments. They were a lot better than the usual refreshments one can expect from a rail company too.
“We have 3 weeks work of requirements we can use, what should we do with them?” asked the poor BA, who had been working hard. “File them in here,” I said and passed him the waste paper bin.
“I don’t want to know how I only want to know WHY,” I said. “We need a vision. What’s the point of it all, why are we bothering to do all this work?”. Each person scribbles a value and a benefit on a post-it. Anything goes and ignore duplicates. After 20 minutes we had a small pile of things customers will benefit from using the planned product.
Taking another 5 minutes we grouped these together into 7 areas and stuck a different colour post-it with the category of customer benefit. These benefits form our vision, our WHY, and our motivation for the work ahead.
Next it was time to derive Epics from the vision and values.
We all wrote down the stories on post-it notes. With big thick sharpies so you can’t write much. We got to 15 epics for the year.
“Next we need to know the size of this lot”, I explained. We used a relative sizing technique explained in a previous post. We broke a few of the big epics into smaller ones and so we now had 19 epics. Once we had them sized, it was time to work out the value. Again using the relative sizing technique we worked out the business value. The PO gave us most of this. Running through the process twice more to work out Time Criticality, and Risk Reduction / Cost enablement. Now using the CD3 calculation of:
(Time Criticality + Risk Reduction / Opportunity Enablement + Value)
———————————————————————————————-
Size (proxy for time)
We were able to calculate the Weighted Shortest Job First (WSJF) and order the 19 items in priority order. (Ok, I might have borrowed this from SAFe)
It was time for a sanity check, and we realised some very big items had been pushed right to the bottom, but the team felt these were much more important. We broke these into smaller pieces as we realised that some parts of the huge epic were highly important, but most of it was low priority.
We now have 21 items, and PO was amazed at how accurate the order way.
As we are dealing with the poster child of Agile product teams, we already have a stable velocity for each team. We could now estimate the backlog.
Oh no! It’s 2 years of work!
Time to figure out the MVP!
Starting with the highest priority items, we identified the MVP part of it and quickly wrote out the items (again on a single post-it for each epic). We quickly did this for the top 12 items as the others were deemed not part of the MVP without breaking down further.
A quick relative sizing of the MVP and we had less than a year’s work.
After a break eating more quality refreshments, it was time to break down the highest priority epic into smaller stories to get the backlog ready for sprint planning. We only have to do 4 weeks (2 sprints worth), so it only took 30 mins.
It was getting rather close to the end of the 6 hour window we all had together, and so it was time to wrap up. In 6 hours, the team had created a vision for the year, a roadmap for 2016, sized the entire work at 2 years, but identified a MVP, which was less than a year, and then prioritised the work and created enough low level stories for the teams for the next 2 sprints.
Presenting this to the Master Uber Controller, gave him the certainty he needed to allow the trains to start running again. Phew! Those customers were starting to stack up on the platforms.
We’ve just saved 2.5 months of work in planning and provided certainty, reduced risk, increased revenue, and taken the pressure off the team and the controller. Not bad for a day’s work.