Four steps to agile planning
Once upon a time there was a team who developed an application…
At first glance, everything looked good. The Development Team was young and ambitious. The application was being written from scratch, so technical debt was very limited. There was Product Backlog. Items in this backlog were estimated in story points. Every two weeks the team held Sprint Review with a presentation of newly developed features.
Looks nice, doesn’t it?
Everything was great until someday one person asked the question: “Hey team, when will we give the first version of the application to our customers?”. And the only answer was awkward silence…
We started to look at the things and we discovered several reasons that made “when will we deliver?” question really hard to answer.
First of all, nobody knew which features should be included in the first version of the application for customers. In other words — we didn’t know our MVP, Minimal Viable Product.
Secondly, the items in Product Backlog were very detailed. Development Team had strong tendency to decompose the items into very detailed and technical pieces. In consequence, there were many small Product Backlog items and nobody was able to order them. Is “Add comment icon to the board” more important than “Display comment panel”? Is “Redirect from short URL to proper page” more important than “Display tagged user in different color”? Hard to say…
The third problem was related to estimations. Only the upper part of Product Backlog was estimated. The majority of the items had no estimation at all. In consequence team was able to forecast the content of next sprint, but they were not able to forecast delivery in 5 sprints from now. And estimating whole backlog of 200 small items looked like huge waste of time.
Facing this situation, we decided to make evolutionary changes for enabling forecasting of our product development.
How did we do it?
Step #1. Think about bigger features
We realized quite quickly, that we were not able to make any forecast basing on current Product Backlog. The items in this Backlog were way too small.
We decided to step level up. We decided to create Epics — bigger chunks of work — on top of the existing items.
During several sessions with the team we grouped all existing Stories and assigned them to 30 Epics. This activity allowed us to obtain two benefits. First of all, we started to work with a list that contained 30 items, not 200. And secondly, when we talked about Epics it was much easier to talk about their business value.
Step #2. Visualize your flow
The next step was to visualize the flow of our Epics.
Our workflow evolved during time, but finally we came into 5-columns Kanban board.
In the first column — “Ideas” — Product Owner could put any item he wanted. And usually these ideas were very vague and general. And it was OK.
We asked Product Owner to move the most important ideas to second column, “Prioritized”. When the Epic was moved in this column, Development Team started to work with this item.
Development Team had recurrent Backlog Refinement meetings. During these sessions, they took items from “Prioritized” column and refined them. This refinement was the conversation for building shared understanding about the item, decomposing Epic into Stories and estimating these Stories.
When all Stories for some Epic were created and estimated — this Epic was moved to “Ready” column. It was the signal that team understood this item, Stories are estimated and are able to start the work.
When first Story from the Epic was taken into Sprint, the Epic was moved to “In progress” column. It was the signal that Development Team has started work and first results will be available soon.
And when all Stories from the Epic were finished, Epic was moved to “Done” column. Simple like that.
So if we mark Epics as big yellow cards, planned Stories as pink cards and completed Stories as green ones — we had the following picture:
Step #3. Let’s start our planning!
When this flow started to work, we were able to start our planning. In fact, it was based on very easy math operations.
For each Epic from “Ready” and “In progress” columns we took all stories and we summed their estimation. So we had rough idea about size of the Epic.
We knew the velocity of the team — we had historical data how many story points Development Team delivered in several past sprints.
So taking these numbers (size of every Epic and team velocity) allowed us to make some time predictions. Let’s say we had a picture like the one below, where number is the estimation of the story. Of course estimation for “done” stories doesn’t matter in planning — they are done, so the estimation is zero.
The sum of estimation on the picture is 57 Story Points. If velocity of the team is 20 Story Points per sprint, then all yellow Epics should be completed within 3 sprints. Simple, isn’t it?
We had a rule that Development Team gave no time predictions for Epics in “Ideas” and “Priorities” columns. If Product Owner wanted to have the estimation for some Epic, it needed to go through refinement process first. No blind guessing and reading tea leaves!
Were we happy in this point? Not yet. We had one more important problem to solve…
Step #4. Remember — Epic is not category!
Quite fast we discovered a very important problem. We estimated some Epic, put it in “Ready” column, started development — but suddenly new stories appeared and were added to this Epic. As the result, estimation for 30 story points could increase to 60 story points… It was like chasing a running rabbit — we run, but our target runs too, so we are still far away from the target.
We discovered that the problem was our approach to Epics. If the Epic is category — like “Images”, “User Interface”, “Architecture” and (my favourite one!) “Reduce Technical Debt”, it’s very easy to add new stories into it. Whenever we have a new idea related to images, let’s say “add feature to rotate images”, it’s very easy to add this idea to “Images” Epic. So all these Epics were natural candidates to grow.
Once we noticed the root cause of this problem, the solution was easy. We decided that all Epics should be big stories — so they should have their acceptance criteria.
In practice we had to decompose several Epics. For example we decomposed “Image” into “Display single image”, “Display gallery”, “Rotate image”. And when Product Owner wanted add new big feature related with images, he had to create new Epic.
But… where’s the Product Backlog?
Some time ago, I told this story to my friend, and he asked me the question: “Does it mean that you had two Product Backlogs? One with Stories and second with Epics? But in Scrum you have only one Product Backlog, don’t you?”.
It’s true, we worked with two boards — one filled with Epics and second filled with Stories. If we look for Product Backlog described in Scrum, it was definitely list of Epics. Product Owner talked with stakeholders about Epics. We discussed their value. Product Owner decided about order of Epics. And Development Team updated Epic statuses after every Sprint Review.
User Stories were only the way to decompose Epic items into smaller and more manageable pieces.
Hey, is it still agile?
Another question I heard was: “Were you still agile? Look, you worked very waterfallish — first you analysed the epics, then you implemented them….”.
It’s true. We had the plan expressed in list of Epics and their estimations. But this plan was very dynamic. Product Owner was able to change order of the Epics anytime. We added new estimations after every Backlog Refinement. After end of every Sprint we updated remaining size of Epics. Product Owner could also remove some Epics if needed.
In reality we had changes in this plan very often. But math to create the plan was so simple that re-creating the plan was fast and easy.
Agile planning — is really it so simple?
In our case we needed to make four steps to enable agile forecasting for our product. Once we discovered these steps — it seemed easy. But discovering them required a lot of experiments and changes.
This solution worked in some context. It’s not said that it will work in all situations.
But it’s definitely worth experimenting to get a transparent picture of current status and reliable forecast for the future!
