How can we go about managing requirements in Scrum Projects? One of the frustrations in a Traditional IT Project is that the Development can only start after the Requirements and Functional Specifications have been completed and Signed-Off. This can take months (and even years in many cases). This is what makes Scrum so revitalizing. Development starts as early as possible. Working Code is Delivered early in the Project. From the start of the project Stakeholders can see that the Product is taking shape. The Product starts as an abstract Concept. Then once there is a partial Deliverable, design flaws and shortcomings can be seen and Changes can be Requested. This is not a problem in Scrum, Change is both expected and welcomed.

Managing Requirements And Change Requests

Change Requests are not just accepted Willy-Nilly, they need to go through an Approval Process, even in Scrum. The reason for this is that the Product is developed as a “Minimum Viable Product”. Only Changes that are important to Delivering a Lean Product can be Accepted. Anything that is a “Nice-to-Have” Feature and does not add to the initial Concept will be declined. To understand the Change Process, we first need to Review how Requirements are Managed in Scrum

Managing Requirements in Scrum.

The Scrum Product Owner is Responsible for the Documentation and Prioritization of Requirements in Scrum. They may even have become part of the original Design Team when the Product was being envisioned. They may have been offered with Business Requirements by the Project Sponsor, who would be one of the Stakeholders.

The Product Owner’s very first Task is to Decompose the Requirements into “Epics”. These are high-level User Stories that will be broken down into atomic User Stories, describing a single activity or Feature. All these Stories will be stored in the Product Backlog in their order of Priority. The most important User Stories will be addressed by the Scrum Team first. The Priority Management is undertaken by the Product Owner. They utilise their knowledge of the business and the expected Product. The Prioritized Product Backlog can be considered as the equivalent of the business Requirements Document Developed for a Traditional Product.

Throughout the Sprint Planning Meeting the Scrum Team (Agile Scrum Master, Scrum Product Owner and Scrum Development Team) take as many top Priority Stories from the Product Backlog as they can Manage in the Time-Boxed Sprint, commit to them and position them in the Sprint Backlog.

The Change Management Process

On completion of the Sprint, a Sprint Review Meeting is held. Within this meeting the Stakeholders examine what the Team has completed to date (current Sprint and any previous Sprints). This is when Change Requests are most likely to occur. There is a Change Management Process that Vets and Validates all Changes before they are added to the Requirements or disposed of. Adding a Change to the Product Backlog needs the Product Owner to Prioritise the Product Backlog. They re-evaluate the Priorities of all the Items in the Backlog in relation to the Change(s) Requested. These changes can be requested during the Sprint Review meeting when the deliverables are being demonstrated to the Stakeholders.

Managing Requirements and Change in Scrum.

Embracing Agile permits flexibility in design throughout a Project. There is a balance between refining the Product Concept and Change for the Sake of Change. In order to strike this balance, there is a Change Management Process. The need for Change can be triggered by a range of internal and external aspects, such as:-.

• ‘Changes to Legislation’ that affect the Product Design (external).
• News of a ‘Competitor Product’ (external).
• ‘Changes in Budget’ (internal).
• Tweaks to Product based upon Deliverables to date (internal).

The Change is formalised through a Change Request Document. The format or material for the Change Request, is similar to a Change/Scope Change Request for a Traditional Project. This is because the Requirements must be Changed if the Change is accepted. In a Traditional Project, this applies to the Requirements Document. In a Scrum Project, the Changes must be applied to the Product Backlog.

The Change Process is highlighted below and ensures that the Change is Integrated into the Project at the appropriate point, without impacting the Sprint in progress.

Define and Document Change:.

• Team has detected a concern and inform stakeholders.
• Stakeholders have determined a vital Change that is required.

Submit for Approval:.

• Change is sent via a Change Request Form.
• Depending on the severity of the Change it might require a greater authority than the Product Owner.

Request Rejected:.

• This should be Done as tactfully as possible.
• Process ends here.

We found these books great for finding out more information on Agile Scrum:

Examine Change:.

• The Product Owner recognizes the impact of the Change on the Product as a whole. The know whether new Stories should be composed and/or Stories currently in the Backlog need to be Changed.

Add/Amend User Stories:.

• The Product Owner determines the impact of the Change on the Product as a whole, and whether new User Stories in the Backlog are updated where needed.

Refine Product Backlog:.

• The Product Owner revisits the Priorities of the Product Backlog and Reprioritise it based upon the effect of the Change(s) Requested.

Await Next Sprint:.

• Depending on the Priority of the Change, it is likely to be Accepted into the next Sprint Backlog.

Managing Requirements: Further Description.

• Identifying that a Change is Required typically originates from the Team, who have actually found a problem during the current Sprint, such as a requirement for additional Security monitoring.
• While lots of Changes can be assessed and authorized by the Product Owner, sometimes additional authority is needed. This authority might be a Scrum Guidance Body, the Project Sponsor, the Program Product Owner, the Portfolio Product Owner or the original Design Team.
• Where a Change is rejected, this might cause some dissension between the Scrum Team and the Stakeholders. Carrying Out Change Management is required to promote a Culture where the rejection is accepted with Grace and Egos are not bruised as an outcome.

We found these books great for finding out more information on Agile Scrum:

Managing Requirements Wrap-Up.

This is a short description of how Change can be introduced into a Scrum. It is not prescriptive, and should be aligned with the Process architecture of the Company. This is especially the case for a new Product Development Process or Project Management Processes.

There is Documentation Required, and a Change Request design template must be designed or obtained from the recognized Project Management Framework.

For those of you who believe that Agile does away with a lot of kinds of Documentation, this is not true. The second Value of the Agile Manifesto states:-.

” Working Software Over Comprehensive Documentation”.

The individuals who signed this Manifesto were all experienced and experts in Software Development. They would be the first to agree that some Documentation is needed, particularly where it adds Value.