A big mistake often made, is the expectancy that when you are going to become agile, everything will be build faster and cheaper. Well, this is simply not true. Building the product faster is not what makes it cheaper, building less is what making it cheaper. Agile is all about building the right thing (and to build it in good quality and deliver as soon as possible, but that’s another story).
So if you want to build less, you probably want to know what you can skip, right? Well, build the things with the highest value and skip everything with very little or none. So it’s all about making the right choices in prioritizing the functionality. Put the highest added value on top of your list (the backlog in an agile environment) and the lowest at the bottom.
It is also important to know how much effort is needed to build a functionality with high value. Imagine, two different functionality’s delivering the same value. One is easy to implement and the other takes time to implement. Which one would you choose? The first one of course. In SAFe there is a formula to make a calculation on this fact:
SAFe is an agile framework for the enterprise. Doing agile on a big scale. If you want to learn more, go to website SAFe. The important one here is, you can calculate a number based on a couple of things that represent the value divided by the job size. The outcome of this calculation can be used to order the functionality’s on the backlog. Now we have a good indication on what to build first and what later (and what never).
What’s left is calculating the values for User-Business Value and Time Criticality and all other values. If you are at a large company, there is probably a lot of knowledge in this area. But how do you weigh them on a scale in a very practical manner? Well, define a couple of metrics you'll find important, rate them a scale from 0..100 and add a weight factor on each one to balance the differences. Summarize all the metrics times the weight factors and divide them by the effort, which can be estimation points like used in the agile environment. Then you get:
So now you'll have a very pragmatic way of making more choices based on what you find important. This really helps if you have a very long list of ideas on your wish list for your product. Just play around with the formula. Change it whenever you feel the outcome doesn’t support your own thoughts when you really look into the priority. If you accomplish that, then you get a nice instrument that quickly helps prioritizing the backlog and provides justification if you need to explain your choices.
In Lerni you can add your metrics on different levels. Add them on strategic level on the themes. Add them to the idea level and add them on the functionality itself (user story’s). Lerni will then calculate a priority index as soon as you add an estimation to the user story. This priority index helps you make your choices in ordering the backlog. Because the calculated priorit is only there to support your own choices, not making the choices for you.
If you also have an opinion on this subject, please comment or contact me. I would like to get in touch to have a chat.
Agile architect, coach, scrum master and developer with a lot of years of experience in different combination roles. Passionate in making ideas a reality. Good ideas and a good open environment with the right people make the impossible, possible. Creativity, the right technology and an open team spirit are perfect to get it done in this time of innovation.