Agile Loves Clear Requirements
Agile Loves Clear Requirements
OpenRose - Requirements Management
An Open Source and FREE Requirements Management Application / Tool
Direct Link to YouTube Video : Agile Loves Clear Requirements
Video Transcript :
Today, I would like to talk about the importance of requirements in project delivery or product delivery, especially when using Agile methodologies like Scrum or Kanban. In the Scrum ways of working, we have user stories that are put into the Sprint backlog. From the Sprint backlog, the team pulls out certain user stories for a given Sprint, which could be a two to four-week Sprint. During this Sprint, the team has daily standups to discuss progress and blockers. At the end of the Sprint, it is expected that the team will deliver a product increment, which could be a service delivery or a product delivery.
Let's consider a project where we have team members, represented by circles. The size of the circle indicates their knowledge, seniority, experience, and skill sets for the product that is expected to be delivered by the team. A big circle indicates a senior-most person in the team with decision-making power and a strong understanding of the business domain. A small circle indicates someone who has recently started working in this industry and has certain educational background but less experience and skill set. This person will be learning as well as delivering for this particular product.
During Sprint execution, we start by taking user stories from the backlog and putting them into the Sprint. We execute the daily Scrum, and at the end, we have a product increment delivered. Let's say we have a four-week long Sprint and we continue doing this for several months. If we start at the beginning of January 2025, by the end of March, we would have delivered three Sprints and three product increments. The team worked very well, and now we are at a point where certain aspects of the product have been completed.
During this time, there were certain changes. A senior person with decision-making power decided to leave, along with a junior person. Additionally, a mid-level experienced person decided to change teams within the company. This last person is still around to answer questions but is not actively working on the product. With these changes, the team will need to replace the members who have left. Replacing team members is not always simple, as it involves handover, hiring new members, and sometimes offshoring or outsourcing certain parts of the product delivery.
The user stories captured during the Sprints in January, February, and March were broken down versions that fit into specific Sprints. They were not complete requirements but small, precise parts that could be tested and delivered within a Sprint. New team members need to understand not just what was delivered but also the contextual information, why certain parts of the product were worked on, and the decisions taken during the requirements elicitation process.
The business analysis team, stakeholders, product development team, marketing team, support team, and test management team all come together to define the real product requirements. They decide on snapshots or baselines and determine further inclusion and exclusion of requirements based on market expectations, company direction, and budget. Without a requirements management tool that contains all product information, newcomers will have to go through all the Sprints and user stories to understand what was delivered and why. User stories may not provide a complete description of the requirements and could be as brief as "As a user, I want to... so that...". It's difficult to understand the overall context and impact of requirements from user stories alone.
That's why I believe a requirements management application is essential. It provides overall contextual information, traceability, and snapshotting capabilities (baselines). With this tool, you can decide on different item types and components that make up the product, and determine which components are outsourced to third parties. Proper requirements management ensures better testing and product delivery compared to just looking at user stories in previous Sprints or Kanban boards.
Let's consider more Sprint execution after March. With changes in personnel, we continue for another three months with a stable team and then have more personnel changes at the end of the sixth month. In the final phase, we have three more months of Sprint execution and are ready to deliver the product. After nine months of hard work, we are ready to hand over the product to a maintenance team or another team responsible for maintenance and future enhancements. The team size may reduce, and the skill sets required for the product will change. By October 2025, we may have different team members, some of whom will stay for maintenance, while others will leave for other projects.
The new maintenance team will need to know the decision-making process and understand the product's history. For example, if the product is a car or a banking application, they need to be aware of critical issues that arise in production. Car companies may recall cars for component replacements due to risks, or banking applications may face downtimes due to issues with new versions. The maintenance team needs access to requirements and decisions made by the original product development team. They may not have access to Sprint backlogs and must rely on product documentation.
Let's say, for example, it's a software application. They got the source code, testing scripts, and so forth. If it's a car, they received information about all the mechanics, the software inside the car, and which company supplied each component to build the car. However, they may not have complete access to fully understand what's going wrong without access to the real requirements and the decisions made during the time when they were working on those requirements.
Those decisions could be documented in a way that gets stored next to the requirement itself, as part of the test cycle, to capture information about how that requirement was actually delivered. This includes the risks, loopholes, and pitfalls that had to be considered in the future based on the design decisions taken by the team during the product development life cycle.
Because of all this, we believe that even in Agile, Scrum, and Kanban ways of execution, requirements remain key and important. They help the maintenance team, development team, and test team to understand what was originally discussed, agreed upon, negotiated, and the context of those individual requirements in the overall large product that we are delivering.
With that, I would like to thank you for watching this video. If you have any specific comments, please feel free to send them over. We would appreciate it if you looked at this open-source requirements management application, OpenRose. Have a great day. Bye!
Comments
Post a Comment