Most project managers have dealt with managing changing scope. It usually goes something like this: “We want it all, just make it happen!” These requests should be expected because a project will change; the scope changes, requirements change, etc. If you are agile and embrace the agile principles, you know this situation is expected. This short post is meant to give guidance around best practices and real-world suggestions.
Changing requirements are welcome and expected in Agile
The fourth value from the Agile Manifesto states “Responding to change over following a plan”, which tells us to welcome change. In agile, changing requirements and scope are expected and the product owner and team must understand that a change in scope requires a tradeoff somewhere else. If using Scrum, your sprints are time-boxed anywhere from 1-4 weeks and if a change is requested mid-sprint you have an option to accommodate those changes if they are small enough to be completed by the time the sprint ends. Otherwise the change may need to wait until the next sprint or be broken down into smaller stories where one part can be completed in the remainder of the current sprint and the other part is slotted to next sprint. Having regular backlog refinement sessions at least once a week allows the team to stay on top of scope change and backlog reprioritization.
Backlog Refinement
In agile, backlog refinement refers to prioritizing and updating the product backlog on a regular basis. The product owner and team should review the backlog items on a regular basis for the next 2-3 sprints, slice the features and/or stories into smaller functional pieces, and re-estimate. I always recommend staying ahead at least 2 sprints because the backlog must always be in a ready state, refinement also makes sprint planning easier for the team. This process is an ongoing, part-time process where the product owner and the team collaborate on user story details. The features and stories are reviewed, revised, and updated by the product owner. The scrum team decides how and when refinement is done.
Prioritization
The team should understand their focus is to work with the product owner to prioritize stories and features. There are different ways to prioritize, such as categorization using a simple 1,2,3 method; T-Shirt sizing using S,M,L, XL; using a high, medium, or low prioritization, or just a simple ordered list.
Each story or feature is listed in order of prioritization. The items at the top, Stories A-D are all part of the Minimum Viable Product (MVP). If scope needs to be cut to meet the timeline or budget, then stories E and F should be cut.
Backlog prioritization also allows a way to accommodate changes during project execution. When the product owner requests a change, the team should then ask what items are more important than the change requested. The change should then be inserted into the prioritized list:
Agile provides a lot of flexibility to accommodate changes but it comes with the price of moving a lower prioritized story below the cutoff to meet the timeline and/or budget. Remember, Agile accommodates changing requirements, however, budget and time are fixed (fixed sprint iteration and fixed budget for that iteration).
Summary
Agile project management welcomes changes in scope. Managing scope change does require a tradeoff of other items in the product backlog. The product owner owns the backlog and has to be able to make these decisions regarding trade-offs between stories and features.
Please contact us if you would like to learn more or have any questions. If you like this post, please share using the share buttons below.