What are Requirements?
In the world of software development, requirements are the foundation of any project. These represent specific needs, functionalities, and constraints that the final product must fulfil. Requirements can encompass a wide range of aspects, including technical specifications, user interface design, performance criteria, and business rules. These requirements provide the blueprint for the development team, guiding the creation of features and functionalities that address user needs and business objectives. Managing requirements in software development is a crucial aspect to ensure the successful delivery of a product.
Challenges with Requirements
One of the biggest challenges in software development is dealing with changing requirements. Specifications, features, functionalities, and user interfaces often change due to various factors such as stakeholder feedback, market dynamics, and technological advancements. Traditional development methodologies struggle to accommodate these changes, leading to delays, increased costs, and compromised quality. This is where Agile methodology shines. Agile embraces change by promoting flexibility, collaboration, and iterative development, allowing teams to quickly adapt to evolving requirements and deliver value continuously.
Breaking Down Requirements into Smaller Work Items
To manage requirements effectively in Agile development, it’s crucial to break down broader requirements into smaller, manageable work items to ensure manageability and clarity on what needs to be developed. This process involves decomposing a large, overarching requirement into smaller, more specific user stories. By breaking down bulk requirements into smaller work items, Agile teams can enhance focus, improve collaboration, and ensure that each piece of functionality is developed, tested, and delivered incrementally. This approach allows for better adaptability to changes and continuous improvement throughout the project lifecycle. An illustration of breaking down broader requirements into smaller, manageable work items is shown below.
Work Items as User Stories
In Agile development, the smaller, manageable work items are basically called user stories. A User Story is a short, simple description of a feature or functionality from the perspective of the end user. It typically follows a structured format: “As a [type of user], I want [some goal] so that [some reason].” This format ensures that the user story is user-centric and focused on delivering some value. For example: As a registered user, I want to reset my password so that I can regain access to my account if I forget my current password.
To ensure that a user story is complete and verifiable, it includes a section on acceptance criteria. Acceptance Criteria are specific conditions that must be met for the user story to be considered as complete or done and to be accepted by the product owner and stakeholders. The acceptance criteria provide a clear definition of what piece of software value is to be created on completion of the user story, ensuring that the development team knows precisely what is expected out of the work item.
Creating the Product Backlog
Once user stories are defined, they are organised into a product backlog. The product backlog is a prioritised list of possibly all work items or user stories that represent the product’s requirements. It serves as a dynamic repository of all the tasks and features needed to achieve the product vision. The product backlog is owned by the product manager or product owner. The product backlog is continuously refined and updated based on stakeholder feedback, market changes, and team input. It provides a clear roadmap for the development team, outlining what needs to be done to deliver the product incrementally.
Grooming and Prioritisation Meeting
An underrated but very important ceremony in Agile development is the Grooming and Prioritisation meeting. During these meetings, the product backlog is reviewed and updated. These meetings involve collaboration between the product owner, development team, and other stakeholders to ensure that the backlog items are well-defined, prioritised, and aligned with the product vision. During these sessions:
- Work items or user stories are prioritised based on their value, urgency, and dependencies.
- New details may be added to existing work items, refining their scope and requirements.
- New work items may be added to address emerging needs or changes in the project scope.
- Bigger user stories may be split into smaller, more manageable tasks.
- Unnecessary work items may be removed to keep the backlog focused and relevant.
The illustration on grooming and prioritisation meeting to review and update the product backlog is shown below.
Estimating Time and Effort with Story Sizing
Once the work items are prioritised, the development team reviews them to estimate the time and effort required to complete each user story based on determining how easy or difficult a work item or user story is to complete. This process is called Story Sizing that involves relative sizing, where work items are compared and weighed against each other to determine their complexity and effort. The team assigns Story Point to each user story, representing its size relative to other stories in the backlog. This practice helps in creating a realistic and manageable development plan.
One of the key benefits of using story points is that, instead of spending time focusing on the absolute size of a user story, the team assigns a number to a user story to represent its relative complexity compared to other stories. This often involves using strategies like the Fibonacci Series to make rough estimates about the effort needed to develop a new feature for an application or to fix a bug. The Fibonacci Series, frequently used in these estimations, includes values such as 1, 2, 3, 5, 8, and 13, where 1 represents the easiest work and 13 the toughest. It should be noted that a story point assigned to a user story does not indicate the number of days required to complete the work item. Instead, it represents the relative size and complexity of the user story. However, the team may use the story point value to estimate an average number of hours or days needed to complete a user story based on its size.
Sprint Planning and Execution
Once story points have been assigned, the prioritised user stories are brought into a sprint during the Sprint Planning ceremony. This creates the Sprint Backlog, which is a subset of the Product Backlog consisting of the work items selected for development in that specific sprint. The Sprint Backlog focuses on the tasks the team commits to completing within the sprint, providing clear direction for that iteration. Unlike the dynamic Product Backlog, the Sprint Backlog remains fixed for the duration of the sprint. Sprint Planning, therefore, involves defining the work as per the Sprint Backlog to be completed in the upcoming sprint, considering the team’s capacity.
A Sprint is a time-boxed iteration, typically lasting 2 to 4 weeks, during which the team focuses on delivering a set of prioritised work items. Sprints run one after another in an iterative cycle. Any uncompleted work items in a sprint are carried over as spillover to the next sprint, ensuring continuous progress and adaptation to changes. With the completion of each sprint, it is expected that a desired value, in terms of feature or functionality, is added to the product under development.
Agile Project Management Techniques
Two popular methods for managing Agile development are Kanban and Scrum. Kanban focuses on continuous development without sprints, while Scrum emphasises iterative development in sprints.
Kanban is a method for managing and visualising work, commonly used in software development, manufacturing, and project management. Originating from Japan, the term “Kanban” translates to “visual card” or “signal card.” In Kanban, work items are visualised using a Kanban board, which is divided into columns representing different stages of the workflow. Each work item is represented by a card or sticky note that moves through the columns as work progresses. Kanban emphasises limiting work in progress (WIP) to prevent bottlenecks and overburdening, allowing teams to focus on completing tasks before taking on new ones. This helps maintain a steady workflow and reduces the risk of errors.
Scrum is a framework for Agile project management that focuses on iterative development, collaboration, and flexibility in responding to change. The term “Scrum” comes from rugby, where it refers to a formation used to restart play. In Agile project management, Scrum involves a cross-functional team working together to tackle complex problems and deliver high-quality products incrementally. Scrum is widely used in the software industry and beyond due to its adaptability to changing requirements, its focus on delivering value early and often, and its emphasis on collaboration and transparency. A Scrum board, similar to a Kanban board, visually represents the work undertaken during a sprint, with columns representing different stages such as “To Do,” “In Progress,” and “Done.” Each column contains tasks or user stories that need to be completed. The Scrum board provides a clear and transparent way for the team to track progress, understand the status of the sprint, and forecast potential delays.
Agile methodology embraces change through continuous or iterative developments, flexible planning, and continuous collaborations. By breaking projects into small sprints, Agile teams can regularly reassess and incorporate feedback. The product backlog is continuously refined to prioritize high-value items, and regular reviews and retrospectives ensure ongoing improvement. Empowered, self-organizing teams can quickly respond to changes, focusing on delivering value with each iteration. This approach ensures projects remain relevant and responsive to evolving requirements. By following these steps, Agile teams can effectively manage requirements, adapt to changes, and deliver high-quality products that meet user needs and business objectives. The flexibility and iterative approaches in Agile enable teams to respond to changing requirements and continuously improve their processes and products.
For knowledge sharing on Agile methodologies, please check our training page. If you have any comments, thoughts, or suggestions on this blog post, please put that in the comment box below.