Requirement Changes Are Put Into The Product Backlog

Agile welcomes changing requirements, even late in development.  Agile processes harness change for the customer’s competitive advantage.

Short feedback loops in Agile allow the team to get fast feedback and incorporate changes required by the customer and reduce the possibility of the team developing the wrong product for too long.

The Product Backlog is dynamic and evolves over the lifetime of the product and requires constant grooming and refinement.  The Product Backlog is continuously updated by the Product Owner to reflect changes in the needs of the customer, new ideas or insights, moves by the competition, technical hurdles that appear, and so forth.

During an iteration, the Agile Team should invest some time to work with the Product Owner to refine the Product Backlog (a.k.a. Product Backlog Grooming).  This includes requirements analysis, splitting large items into smaller ones, estimation of new items, and re-estimation of existing items.  Priorities can change and requirements can move up and down in the Product Backlog.  When new items are discovered, they are inserted into the Product Backlog causing the lower ones to move down the list (and possibly fall outside of the scope of the release) or old requirements removed as appropriate.

Although Agile welcomes changes, when using time-boxed delivery like Scrum, there are no changes allowed during the iteration, and the end date of the iteration does not change.  In return for not making changes during the current iteration, the Product Owner can make any changes they want to the Product Backlog before the start of the *next* iteration.  The Product Owner can add, remove, reorder, or change items before the start of the next iteration.  This enables the Agile team to make and keep commitments, it gives the team focus and stability during the iteration, and it trains the Product Owner to clearly think through what is in the Product Backlog.  Due to the short time-boxes, the team should be able to get some reasonable certainty into the planning and requirements and avoid churning during an iteration.

Overtime if you find that the Product Owner keeps needing to change requirements mid-iteration, then perhaps the iteration length is not short enough.  Plan iteration durations around how long you can commit to keeping change out of the iteration.

Managing Defects on Agile Projects

This recent Dilbert comic strip reminded me of a situation when a client was raising cosmetic defect as severity 2.

It is often not clear what a defect is and at what level to raise it at (despite agreed severity descriptions) as my example above shows.  And some defects are raised without being related to a requirement. Or defects raised because of a feature being “not user friendly”.

Regardless of the reason and how you label the ‘defect’, I treat all defects the same – it is a piece of work required by the client that needs to be prioritized with other work. So the approach is to put all work (defect, enhancement, new feature etc) into the product backlog. As part of the planning process, the Product Owner will prioritize the items on the backlog for the next iteration and/or release. So if a cosmetic defect is more important (has greater business value) than a new feature, then it should be placed higher so it gets completed first.

Keeping all work in the product backlog, makes planning simpler and helps manage the flow of work. It also ensures the client is in control and be the judge of what is important to their business.

%d bloggers like this: