The Product Owner is accountable for the Documentation and Prioritization within Requirements Management in Scrum. The Product Owner might have been part of the initial Design Team. They may have been provided with Business Requirements by the Project Sponsor, who would be among the Stakeholders. The Product Owner’s very first Task is to Decompose the Requirements into “Epics”.
These are top-level User Stories that will be broken down into smaller User Stories, explaining a single activity or Feature. All of these User Stories will be stored in the Product Backlog in their order of Priority. The Priority Management is carried out by the Product Owner, using their knowledge of the Business and the expected Product. The Prioritized Product Backlog can be considered the equivalent of the Business Requirements Document Developed for a Traditional Product.
Requirements Management & the Sprint Planning Meeting
During the Sprint Planning Meeting the Team take the top Priority Stories from the Product Backlog. The select as many as they can Manage in the Time-Boxed Sprint. They commit to them and position them in the Sprint Backlog.
When the Sprint is concluded, a Sprint Review Meeting is held. This is where the Stakeholders examine what the Team has completed to date (present Sprint and any previous Sprints). This is where the Stakeholders can request change.
There is a Change Management Process that Vets and Validates all Changes. These change requests will either be entered into the Product Backlog or disposed of. Including a Change to the Product Backlog requires the Product Owner to Prioritise the Product Backlog, re-evaluating the Priorities of all the Items in the Backlog in relation to the Change(s) Requested.
Requirements Management & Change in Scrum.
While the whole reason for adopting Agile is to allow for flexibility in design during 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 caused by a variety of internal and external factors, such as:-
- ‘Changes to Legislation’ that impact 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 content for the Change Request, is recommended to be comparable to a Change/Scope Change Request for a Traditional Project.
Requirements Management & the Change Process
The Change Process is highlighted listed below makes sure that the Change is Integrated into the Project at the suitable point, without impacting the Sprint in development.
Specify and Document Change:.
- Team has found a concern and notify stakeholders.
- Stakeholders have identified an important Change that is required.
Submit for Approval:.
- Change is sent via a Change Request Form.
- Depending on the seriousness of the Change it may need a higher authority than the Product Owner.
- This must be Done as tactfully as possible.
- Process ends here.
- The Product Owner recognizes the impact of the Change on the Product as a whole. They determine whether brand-new Stories must be composed and/or User Stories already in the Backlog must be Changed.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Add/Amend User Stories:.
- The Product Owner identifies the impact of the Change on the Product as a whole, and whether new Stories in the Backlog are updated where required.
Refine Product Backlog:.
- The Product Owner reviews the Priorities of the Product Backlog and Reprioritise it based on the impact of the Change(s) Requested.
Await Next Sprint:.
- Depending on the Priority of the Change, it may be Accepted into the next Sprint Backlog.
There are a couple of points that need extra description.
- Identifying that a Change is Required may originate from the Scrum Team (Scrum Master, Product Owner and Development Team). They may discover a problem during the current Sprint that requires a change to be made. These may be items such as a requirement for additional Security checking.
- While lots of Changes can be examined and approved by the Product Owner, often additional authority is required. This can take various forms depending on how Scrum is embedded in the Organization. Approvers could be a Scrum Guidance Body, the Project Sponsor, the Program Product Owner, the Portfolio Product Owner or the initial Design Team.
- Where a Change is turned down, this could trigger some dissension between the Team and the Stakeholders. This is observed particularly where Agile Scrum has been embraced recently by the Organization. Conducting Change Management is required to foster a Culture where the rejection is accepted with good Grace and Egos are not bruised as a result.
This is a short description of how Change can be presented into a Scrum. It is not authoritative, and should be lined up with the Process architecture of the Company, particularly for a new Product Development Process or Project Management Processes.
There is Documentation Required, and a Change Request template needs to be created. For those of you who think that Agile gets rid of many forms of Documentation, this is not strictly true. The second Value of the Agile Manifesto states:-.
” Working Software Over Comprehensive Documentation”.
The individuals who signed this Manifesto were all skilled and specialist in Software Development and would be the very first to agree that some Documentation is required, especially where it includes Value.
The ‘Agile Scrum Master Training Course With 59 Seconds Training‘ is now available for free. This free Scrum Master Certified Online Training Course provides an in-depth understanding of the Agile Scrum Master roles and responsibilities, where you find out what a Scrum Master does and how to do it. During this free course you will learn all of the tools needed to succeed as an Agile Scrum Master.
Thank you for choosing us to learn about the Agile Scrum Framework.