Image may be NSFW.
Clik here to view.
On many software development projects, teams that are interested in getting started writing code early start by building the things they understand first. While this gets code started and in front of the customer as soon as possible, it isn’t necessarily the shortest time to value. This approach also sets the team up for the later stages of the project to be wrought with uncertainty and pressure from the business. Two keys to successful Agile projects are focusing on early learning (mitigation of risk) and then rapid time to business value. This is achieved by prioritizing the order that work is performed by the team. When requirements analysis doesn’t clearly communicate the areas requiring risk mitigation and clearly identify those requirements that are most valuable to achieving the business outcome, then the team can’t appropriately prioritize the work.
Requirements reflect business value and risk
On most software development projects, not every requirement is equally valuable to the business. Some requirements are core to achieving the business outcome expected for the project and some are critical because they are deliver on the brand of the business. But others, while valuable to the business, may address edge conditions or be nice to haves. Requirements need to be prioritized so that unknowns are addressed early, then higher business value requirements are addressed, then the remaining requirements. Part of the requirements analysis process should include an assessment of business value and risk. If the prior principles have been applied, but the requirements are not worked with an eye toward risk mitigation and business value priority, the team will not be optimizing investment or time to value.
Because software development has some level of uncertainty, it is likely that a project will reach the end of its budget or time estimate before delivering on all the requirements expected. If you haven’t prioritized business value and risk, you may have to report, “We are really, really close. For just a little more investment or time, we can deliver something that meets your needs”. It is far easier report at the end of the time constraint or budget and say, “We have delivered on the most critical features and addressed the primary risks. At this point you can use the system we have delivered to address (most of) your business need. However, if you want to continue to invest, we can add additional capability.”
Many projects wait until the project is in danger to begin the trade-off analysis. Early work is done to a great deal of detail and late work is rushed through. The time to triage the requirements is at the beginning of a project. Then at each stage of elaboration, the detailed requirements should be further triaged. Requirements must reflect business value and risk – and the work should be prioritized based on these factors.
