There is more to calculating ROI than a simple equation. It can be affected by risk, time, and other factors—including whether your team is agile. Releasing software immediately after coding and testing accelerates feedback cycles, minimizes the cost of delay, and increases return on investment. Allan Kelly tells you how.
Using effort estimates as the only criteria for deciding whether work is undertaken could be leaving money on the table. Considering value—in particular, the effect of time on value, as in whether there is a cost of delay—makes for more intelligent conversations and better decisions.
In the public sector, a change in standard processes and procedures requires significant effort and, often, approval from external vendors and elected officials as well as internal stakeholders. To get buy-in to become agile, you have to utilize all Scrum tools at your disposal to show the value of the proposed agile process.
You can use analytical methods to assign business value to a user story, of course, but another way is simple estimation. Allan Kelly describes an estimation exercise that combines the Scrum tool of planning poker with a TV show format to add some fun. You end up with enlightening conversation and revealed requirements.
Business stakeholders and DevOps teams both have to take an active approach to app development, but neither faction should have to change practices and processes in order to get their needs across. Investing the time to establish communication between these teams will drive delivery of the applications customers demand.
Communication is always vital on an agile project to ensure everyone is on the same page, but it's perhaps most important in a relationship between a vendor and a customer. Here, Marcus Blankenship relates a personal story about a project where communication failed, and gives some good tips for how to avoid it happening to you.
Instead of choosing what to develop based solely on a cold, hard dollar amount, you might try approaching the person who originally requested a story—or who will be most affected by it—and asking, “What benefit will this bring you?” Armed with a list of stakeholders and interests, you can find out the real difference a story will make.
Allan Kelly says that ideally, companies should put a dollar amount on each planned business decision. But pinning down financial value can be hard, and besides, there are many other factors to consider, such as sustainability and customer service. He looks at various ways to assess the business value of user stories.
If you really want to get the benefit of Scrum, you have to make the mind shift to product ownership, not project management or project ownership. The product owner role is often thought of as being a requirements specifier, when in fact a good product owner is a value maximizer, and a great product owner is a product maximizer.
Some teams only work with stories, but it can be difficult for a team new to agile to write stories that are easy to understand and provide value every time. An alternative is to add epics and tasks. Understanding the differences between each level and knowing what size story to use for each situation will improve the accuracy of your sprint planning.