Prioritizing software requirements across releases
When prioritizing requirements for the first release of our software, we’ve stressed the importance of including 100% of the ‘must have’ requirements in the first release of the software. We’ve also used Kano analysis to categorize requirements as ‘must be’, ‘surprise and delight’, and ‘more is better’ requirements. In this post we’ll talk about an approach to allocating these requirements across releases.
Simplifying assumptions
Every guideline includes implicit assumptions. Most useful strategies make simplifying assumptions to ease communication of the basic ideas. Readers are left with extra homework to determine the applicability of the advice to their unique situation. The ideas presented here are no different.
We are assuming that we are prioritizing requirements for a software application with a single user class. There is an added level of complexity that has to be addressed in rolling out software – the scheduling of use cases across releases, as they will be enabled for different users. We’ve writen about communicating a release schedule using use cases. Within that context, we apply the ideas presented in this post. But we will remove that layer of complexity from this discussion.
We also strongly believe that ROI should be the primary driver of scheduling decisions. In this post we will assume that there are many requirements in each of the Kano categories with varying net present values . When this isn’t true, the strategy presented here should be updated to account for the specifics of the current project. Within each release of the product, and in each category, we should focus on the most valuable features first.
Scheduling of releases
The first release of the software must include all of the “must be” requirements. The level of effort required to implement all of these requirements drives the scheduling of the first release. The amount of time required varies by project – it could be anywhere from weeks to years. With an iterative development methodology, the team may be managed to deliver multiple internal releases prior to the first external release – but there should never be an external release before all of the “must be” features are complete.
Additional releases of the software should be time boxed based upon the desired release frequency for the product. A time box is an arbitrary amount of calendar time allocated to a particular release. Releases could be scheduled monthly, quarterly, or at any other frequency. Note – releases of patches (critical bug fixes, security updates, etc) can and should be delivered ASAP, and not held until the next timebox is completed.
The efficiency of the development process will determine how fast a team or company can roll out new software – some percentage of effort is involved in deploying the new software (even if the build process is fully automated, the end user will experience some overhead in upgrading). Our experience has been that 3 weeks is the shortest cycle that can be both delivered without overhead costs becoming too expensive and without user updates becoming too burdensome.
A release frequency of more than six months runs the risk of users perceiving the software as becoming stale. Our recommendation is to release between monthly and quarterly.
Allocation of effort in the first release
We mentioned that all of the “must be” requirements must be included in the first external release. We also suggest including some “surprise and delight” features. Geoffrey Moore reminded us that it isn’t enough to be innovative, our product needs to be differentiated.
[…]it is good to differentiate on an attribute that drives customer preference during buying decisions
If we have competitors, then our “must be” requirements will not differentiate us – because our competitors must have those features too.
We should allocate our efforts for the first release as 80/20 in terms of effort spent on “must be” and “surprise and delight” requirements. Dedicate one developer on a five person team as the “differentiator” for the release. Or have the development team organized around “fun stuff Fridays” where the focus is on the differentiating “surprise and delight” features.
This approach absolutely delays the first release of the software (relative to only implementing the bare minimum capabilities).
This approach also creates the opportunity to present a compelling message about product differentiation.
Allocation of effort in incremental releases
It is likely that we will have uncovered new requirements during the first release cycle, possibly even new “must be” requirements. As part of our process, we will prioritize the new requirements relative to the unaddressed requirements from the previous iterations. We should spend our time 50/30/20 on the implementation of (new) “must be” / “surprise and delight” / “more is better” requirements. When we don’t have enough “must be” requirements to fill half of our time box, we should adjust the times, while maintaining the 3:2 ratio of “surprise and delight” and “more is better” requirements.
This allocation assures that we are spending time on the most important stuff. It also makes sure that we are presenting the users with a perceivable track record of continuous improvement. Don’t ignore the “more is better” requirements – the incremental improvements will add up over time. Without this investment, we create opportunities for our competitors to differentiate against us – “Sure their software works, but it takes an hour to process each transaction. We can do it in two seconds”
What about bugs?
Bug fixes should be prioritized just like every other requirement or feature. A value must be assigned to resolving the bug. If that value-to-effort ratio is higher than the ratio for “new feature X”, then the bug takes precedence.
Conclusion
Our first release has to have all the features that users demand. It also should have differentiated capabilities in order to compete with existing products.
Additional releases should allocate half of their time to product differentiation – both in terms of “delight” and in terms of “more is better”. Keeping and communicating an explicit allocation (or allocation goal) will help us resist the urge to push off “unimportant” requirements until they become important, or even worse, irrelevant.
Differentiating features are important.
When doing a RUP project, the differentiating features are looked after and documented in the Vision document, in the “Product position statement”. That statement has the form:
For our customers
Who have
Our product has
Unlike our competitors products
We even have
The product position statement is a great tool for MoSCoWing (deciding whether a proposed new feature is Mandatory, Should have, Could have or Would/Won’t have). It the proposed feature aligns with the product position statement, include it, otherwise drop it!
Another rule of thumb on including/excluding features is that you need to keep some features for the next release in order for the customer to be willing to do an additional pay.
If all nice features are in your first release already, why would he bother bying your next release…
Another benefit of multiple releases is sustained interest in the software. I read an article by someone who tracked his software sales for a product over a couple years. He found that both revenue and revenue growth correlated with frequency of update of the software. I wish I had tagged the link to share it, but I didn’t. Sorry.
Thanks for the comment/trackback!