For many project professionals, managing a backlog of user stories in an agile project can be done in their sleep. But what determines priority and how does that contribute to delivering the expected benefits?
One of the key tenets of agile project delivery is the flexibility of allowing for a more iterative and change-accepting approach regarding scope, ensuring that the most value-adding items are delivered.
It’s not an approach that is free of constraints, not by a long shot. Instead, agile project teams will take a firm view on time and cost – called time-boxing – and acknowledge that the limitations of resources and time enables the team to focus on breaking down and prioritising the scope to ensure that a benefit is delivered.
The role of the project owner is critical to success, given the responsibilities they hold in defining, prioritising, and approving or rejecting the work the team delivers. Doing a ‘good job’ is rarely enough to guarantee a good result, and the role the product owner plays is very difficult to do well.
When agile processes are followed well, and to a high and aligned standard, an agile approach can maximise the potential of the return on investment and deliver the benefits a project seeks. When these processes are anything less than executed well, the risk of delivering no value at all is palpable.
So what are the challenges a project owner might encounter, and how do they put benefits at risk?
Prioritisation Constraints
Time-boxing is a technique that will result in a project having limited resources to deliver the list of the desired scope. It’s common to start a project with more scope than there is funding to deliver, and even if it doesn’t start with that as a challenge, the opportunity created by doing smaller pieces of scope in iterations allows the team to identify new items with potentially greater benefits.
The diagram to the left illustrates how constraints will impact the backlog when a line is drawn between what is prioritised and fits in the funding envelope and what isn’t prioritised or funded.
The product owner is responsible for prioritisation – in effect, deciding what is above or below the line. The ability to make the right decisions around prioritisation requires a deep understanding of customer needs, preferences, and pain points, as well as the goals and objectives of the business. It also requires having a clear vision of the product.
But how do they reach the decisions around what to promote and what to de-prioritise?
Prioritisation Factors
Irrespective of whether a project uses agile or not, there are many factors that need to be considered when a product owner chooses what to prioritise and what not to prioritise. For example:
- User Impact: Consider how the user story will impact the end-user experience. Will it improve their experience or solve a significant problem?
- Complexity: Consider the complexity of the user story. Is it a straightforward task, or does it require a lot of development effort and resources? This factors is more useful when considered in conjunction with business value.
- Dependencies: Consider any dependencies that the user story has on other stories or features. Will it be easier to complete this story before or after another? Is this story required as part of a set to deliver a meaningful experience?
- Risk: Consider the level of risk involved in relation to user story. Does it involve any technical or business risks that could impact the project’s success? Is there likely to be re-work or excessive use of time and resources that should that occur would lessen the value of the story.
- Time and Cost: Consider the time and cost required to complete the user story. Can it be completed within the given timeframe and budget, and does it provide a meaningful return on investment?
- Business Value: Consider the business value of the user story. Does it provide significant value to the customer or end-user? Does it address a critical need or problem? Does completing it move the project closer to achieving the goal?
As the scope is broken down into many small items in agile projects, it can become very challenging to determine how much each item contributes to the overall benefits that the project is ultimately seeking to deliver.
The Prioritisation Process and Context
There is a theory around change that underpins a project, including agile projects. That benefits are a positive outcome achieved by delivering the desired scope.
There is a little more to it. Typically a project starts out with goals and objectives, which are translated into scope and deliverables. The relationship between the factors and the context provided by the project’s goals and objectives are important ingredients in the prioritisation process as they help provide greater meaning to each user story.
Let’s consider what each component represents:
- Goals: Describe the high-level outcomes or benefits that the project aims to achieve or affect; for example, a project aims to improve the overall customer experience by 10%.
- Objectives: Specific, measurable, and time-bound targets that must be achieved to meet the project goals. They are often broken down into smaller, achievable milestones. For example, if the project goal is to improve the experience by 10%, an objective might be to improve the speed of order processing and accuracy to reduce customer complaints by 25%.
- Scope: Establishes the boundaries or limits of what the project will include or exclude. It defines the features, functions, and tasks that will be part of the project. For example, a website development project scope could include designing and building a website but exclude creating marketing materials.
- Deliverables: Tangible, measurable outputs or outcomes that are produced as a result of completing the project work. Deliverables could be products, services, documents, or reports. For example, the website development project deliverables could include a functional website, customer forms, associated knowledge articles and chat services.
There are many inputs and considerations a project owner must make when deciding on the backlog for an agile project and these must be made in the context of the project’s goals and objective definition, which should enable the project owner to weigh the merit of each factor and determine the value for each user story and how it contributes to benefits.
Maintaining a Laser Focus on Benefits and ROI
Product owners should seek stakeholder input, feedback, and collaboration to better understand the potential impact or consequences of how they prioritise user stories or groups of stories. This can also provide perspective on how complex or costly they may be to implement and provide insight on the stakeholder’s view or understanding of what’s expected in terms of the return on the investment.
The interrelated nature of these elements demonstrates that there is never a linear or simple process in prioritisation; user stories and how they are prioritised cannot be cherry-picked in isolation without some effect on outcomes. Value-adding components might be delivered but not melded together in a coherent solution.
It is vital that product owners are able to keep a laser focus on benefits and ROI in how they make decisions about how they break down the scope and decide which user stories are included or deprioritised.
As project specialists, Quay works with clients to ensure their projects are set up for success. Contact us here to find out more about how we work and support your teams.
We believe that quality thought leadership is worth sharing – click on any of the links below to share with your colleagues. If you’re interested in republishing our content, here’s what’s okay and not okay.