The Poetry in Software Releases

How to plan the unplannable

One of my Product Owners is outing her concern about our backlog to me. There is no way that we can do everything she wants to have with the budget that we have been given. It is my turn to tell her one of the wisdoms that I have learned in all these years of software development:

"Plan as if you will not get any more budget"

Must, Should, Nice to Have

We all know them, the castes of software features. Every Product Owner worth his salt would try to categorize the features of her product in these 3 buckets. And we all know that the Nice to Have is already a veiled "won't do". It is like when you tell your kid that she will get that ice cream when we get home, knowing that she will fall asleep in the car.

The real problem is all the "Should". Especially once you have a first version of the software in the field. Suddenly bug and feature triage creep in. "This feature would be really cool, but if we do this other improvement we would get a bigger order from this other customer". And suddenly we leave the yellow brick road and get lost in the forest of improvements and bug fixes.

And the output of the project team will get dragged down by unplanned issues introduced because of an operating system update, or an urgent security fix, or as banal as the end of life of an API that you rely on. So, what do you do in this case. My answer is: Measure your velocity, and plan as if your budget is all you have.

Velocity

One of the nicest features of Scrum SW development is that if you do feature refinement correctly and assign points to every task that the team works on, you will be able to measure the velocity of the team.

Let me explain this using a car analogy. One of the most important sensors in your car is the one that shows how full your tank (or your battery, if you are driving an electric car), is. Most modern cars will have also an estimation of how far you can drive with the load you have.

Scrum allows you to calculate a similar metric by means of velocity. Velocity is how many points can your team in average finalize every sprint. This can only be done if you are assigning points to your stories in the scrum Refinement meetings. Tools like Jira will calculate the velocity automatically for you.

All that is left to do is to sum the points of your "should" stories and divide them by your team velocity. Knowing your budget would let you know how many sprints you can still afford, and you can plan accordingly.

“Deciding what not to do is as important as deciding what to do.” (Steve Jobs)

I know it is cheesy to quote Steve Jobs, but this is one of his wisdoms that has saved me more than once.

Call to Action

If you are a product owner, calculate your velocity and use it to shape the list of "Should"s in your backlog. Make sure you do not plan your release until the very last sprint. You would not choose to drive to the gas station on the last drop when you drive.

If you are a scrum master, make sure you start calculating the velocity early and make your product owner and team members aware of its importance.

If you are a software developer, try to be accurate in your estimations. If you are too conservative you might remove some important features from the product. If you are too aggressive, you risk the project running out of gas before you ship the final version.

And quoting Paul Valéry: "A poem is never finished, only abandoned". Good software is indeed like poetry. If you don't believe me look at all the games that live on despite not being supported anymore by their publishers. Many a poem would like to be so popular.

First Published here