Let’s go back in time: Think about any software that you’ve ever given a user. You have an idea to build a system to aid a painful business process in your organization. You fight with management to get a massive budget to be able to build the system. You then go through the entire painful traditional software development process and you get your perfect piece of software within time and budget constraints. You give this software to your users with all the bells and whistles that they asked for. At first they don’t know how to use it and they’re going up the learning curve. With time they’ll master the use of the system, but (statistically) end up using less than half of the features they asked for. Like any tool you master, you eventually find ideas for improving the tool. Now users start to complain and to ask for new functionality. You wait and wait because you’re trying to squeeze the maximum amount of ROI from the system you fought so hard to build, until you must give in. You now restart your process fighting for a massive budget again to rebuild something that is no longer relevant for your business or the market. SCRUM offers a different approach to all of this. When you read about SCRUM, one of the key points you hear about is the Product Backlog.
It’s a beautifully simple way of managing requirements for a system. Indifferent of the level of detail a requirement comes in, it’s quickly and painlessly documented as a User Story, prioritized and managed from there on through the construction of the system. However, quick SCRUM tutorials fail to address one of the best uses for a Product Backlog: A Product Backlog can be the way you manage the roadmap of your entire IT software portfolio. Let’s go back to the story above and do it the “SCRUM-way”: You have an idea to build a system to aid a painful business process in your organization. You don’t have to fight with management for a massive budget, you only ask for a monthly burn rate to develop a new system. You assemble a team within your monthly burn rate and get started. Ideas constantly come in during the entire project. You document them and prioritize them. During each Sprint, you only build a few of the most important requirements. After a few iterations, you feel you’ve got a new version of the system ready.
You release it to your users. Your users will use the system immediately, because it’s still quite small or only a little bit of it has been added. You continue building while they use the system and generate even more requirements that you prioritize and change. Note that this process seems to be never-ending, but there’s a step that makes it beautifully come to a close. When planning each Sprint, you look at the requirements that are included to be built during the Sprint. You ask yourself: Is it worth the cost of a Sprint to get this built into the system? If the answer is “No” you have a fully finished product. Until… the business changes and more requirements come in that are important enough to change that answer to a “Yes” and you continue building your system. You now have a complete roadmap for each one of your systems.
Want to give it a try? Contact us and try this proven way of developing software!
About us: Perficient Latin America is a nearshoring 30 year old IT services firm with offices in the Colombia, Mexico and the US that combines high level process maturity with agile methodologies in order to reduce the Total Cost of Ownership of software development projects.
