There is a misconception that Agile means no documentation. But requirements are the necessity to create the software. So it is all about an efficient way to capture requirements in agile. It produces useful documentation which helps in delivering the right requirements.
This post will guide you on how to capture requirements in agile or any other methodology. Traditionally, requirements are defined in a document, which often few reviews, are signed off and suit to the development team for coding. It is applicable to the waterfall model.
What are Requirements? and how to capture it correctly?
Requirements Definition
In Agile methodology, however, the entire set of requirements is broken into smaller pieces of works(tasks) which can be completed in shorter cycles.
The requirements are mostly defined in the format of stories that are written from the perspective of the user (for whom ) with expectations (what) and intended benefits (why and its value).
The initial requirement can be one liver, however, it does not mean that the requirements are unclear when the team is developing the software. The team gets clarity during a session of interaction.
A healthy talking or debate with product owner (PO) during release or sprint level planning meetings resolves most of the doubts.
To get requirements in shape, they are groomed regularly and refined or ongoing basis. There are functional and nonfunctional requirements (NFR).
NFR enforces some constraints and defines boundaries of acceptable behaviour of the system such as expecting the system to respond to a user action indefinite time or perform a certain way under define user load and stress.
Quite often, this important aspect to capture NFR as the art of user story is missed and could result in software that is working but not meeting expectations.
Requirements definition should ensure that they are defined just enough to estimate fairly and deliver value in short cycles.
Some of the practices such as including mockups/wireframes, reference points in the requirements specifications, can help developers understand and deliver better.
While defining requirements for execution, they can be defined at a high level which can cover the system as a whole and then can be broken down in smaller independent pieces.
Here a discovery and requirement workshop of a few hours or days (based on the quantum) is a recommended practice. It helps the team and all stakeholders to get enough clarity for the small requirements from the large chunk.
Role of Product Elevates statement, Product vision, Product Map/Story Map while defining the requirements.
Before even we move to understand requirements a bit deeper, it is good to understand and have some clarity on vision or have the elevator statement with a kind of workflow identified as a product map.
Elevates statement
It provides an understanding of the feasibility and value of the product or project under development. The components of the elevator are as follows-
- For (target customer)
- Who (statement of the intent or market opportunity)
- The (product or project) is a (product category)
- That (key benefits or compelling reason to buy/ use)
- Unlike (primary competitors/ competition, alternative products)
- Our product (primary differentiators).
Similar to the stories can be defined based on the user groups acting the feature. This technique gives due importance to the usability aspect of feature which is ignored many times-
- Who will be using it (used, user group) Age, Gender, Education.
- Why is it required -Needs, Expectations.
- What we want to accomplish -Goals using this product.
- Where (Environment) -Where, type of computer
- When -Frequency of use, triggers for use
- How many/ how important (impact/value) -Percentage of the user base, the value of these users
- Name and possible nickname (of the actual group if known gives precise understanding).
Role of Product Version while defining requirements
Product version which encompasses all the aspect of a product used by many product owners (PO) before defining defeated product backlog.
In this activity, the PO comes up with activities/expectations from the product as in ‘What the software will do’ based on which team and PO brainstorm to define stories for each of the activities. Now, defining these activities in a column and putting all related stories below that will create a grid-like structure that gives a better perspective of product scope and boundaries.
Role of Product Backlog (PB) in Requirements Gathering
The product backlog is the artefact that holds an entire set of requirements which is equivalent to requirement specifications of the traditional model. It is usually an ordered list of all requirements that are required by business stakeholders.
It is kept ordered by the product owner who owns it. While the current work is in progress, PO has the liberty to change everything in product Backlog and can define, remove or add a new work item. The defects and technical debt (the material that provides efficiency to the codebase or existing tech processes) are also part of the same.
Top-ranked work items are expected to have enough details for the team to pick up if and when they need it. The backlog is always dynamic and reflects the responsive nature of the framework. Sometimes, the work item in the Product Backlog is also sized with story points to give a rough idea or the relative complexity and effort.
Product Backlog is groomed in a separate session or in a sprint planning meeting. In the grooming session, the stories are explained, defined in additional detail alongside acceptance tests. Quite a few times, the size estimates are also calculated in this meeting.
It is recommended to spend approximately 10% of the sprint time in grooming sessions to ensure the continuous availability of well-defined stories. The story groomed Vs. The total story backlog for every release can be considered as one of the metrics to capture.
A well-groomed backlog often plays a pivotal role in the successful execution of Agile projects. A product backlog (PB) is DEEP (Detailed appropriately, Estimated, Emergent and Prioritized) technique follower. (Mike Colm and Roman Pitcher).
There is a risk associated with making a product backlog too DEEP( Detailed appropriately, Estimated, Emergent and Prioritized).
It means that not all the stories in the backlog need to be detailed but higher-ordered stories should be. As you move downwards, the details might thin out and stories become larger, similar to Epics/ Themes, one-liner or just a statement of intention (idea).
Similarly, at least, top work items in the backlog should be estimated in story points or using any other sizing mechanism to help the team prioritize them while planning to release, based on available capacity.
The emerging nature of product backlog is something that shows whether the team is really listening to feedback from customers and internal stakeholders to keep product backlog evolving and ordered with the addition of new stories and changing existing ones continuously.
The grooming activity of the backlog should be done on a continuous basis by the PO to get the real benefits of Agile development. The short iterations are meant to deliver what would be of higher value to the business. Only rightly ordered backlog will ensure that item delivers what the client needs rather than what is perceived as needs.
Analyzing existing product features while grooming requirements
Packages come with out of shelf features. Many user stories in the backlog can be linked-to enabling a module in the package or doing some configurations in the package. The creation of user stories or the grooming with details can be done with respective of these available functionalities/modules in the package.
Role of known product bugs and limitations in requirements
The out of the box features of a package may have known product deficiencies which could be running. Counter to the business needs or objectives. This needs to be studied to packages’ release notes and can be brought into the sprint items depending upon the impact.
Knowing Package Architectural Demand
A package implementation may demand implementation in a certain order or in a certain fashion owing to its architecture and hence user stories in the product backlogs have to accommodate the same.
Role of Sprint Backlog in requirement gathering
The sprint backlog is a list of all the requirements that the team collectively commits and forecasts to complete based on their past record.
Once the work begins on iteration, Sprint backlog does not change. Now work discovered is created as a new work item in the Product backlog and prioritized by the Product Owner.
The sprint backlog is a list of user stories and the team is expected to complete them in the order. They were assigned. The work items or stories in spirit backlog have clear acceptance to ensure a successful spirit.
Techniques for Requirement Categorization
In Agile exertion, requirements or work items are classified at different levels. The factors considered these classifications are- Slope of requirements, dependency to deliver in clusters and efforts.
In addition, enhancement in the workflow in existing feature which has some team called Business Initiatives is also recommended to be written in terms of user stories to maintain consistency.
A defect (deviation from the requirement) is also sometimes a change request or new requirement in the grab of bug. It identified, it should be converted into a story.
The theme, Epic, User story :
The widely used technique for clarifying the requirements is sized based SMC (S-Small, M-Medium, C-Complex) or based on various factors like dependency, unknowns, risk, and uncertainty.
In Agile, requirements are primarily defined based on values to business (ROI – Return on Investment) and how they revised over the project execution timespan. Requirements are broadly classified as – 1. The theme, 2. Epic, 3. User stories.
Theme
A theme is a very large requirement and may, sometimes, encompass entire product vision. Most of the times, a theme is a set of interrelated requirements which are considered as a bunch for release planning.
A large theme can be subdivided into multiple sub-themes. Development of a theme can span from a few months to a year.
Epic
An Epic is a very large requirement that can’t complete in a short iteration (Spirits) and hence, needs to be broken down into user stories. An epic can be considered as a small theme by virtue of its magnitude and sometimes, is talked about as one and the same.
A user story:
A user story is a feature, small enough to be delivered in iteration and represents unique business value. Generally, an Epic is delivered into multiple user stories.
It is mostly a vertical Slice cutting across all phases of SOLC and has tangible business value. A user story can also represent technical debt which does not represent business value directly but is required for better and maintainable Core quality.
Requirement Prioritization
Requirement Prioritization is the most important aspect around which Serum/XPs deliver high-value requirements faster. The prioritization is a value-driven approach and forces business stakeholders to define requirements which would be completed by the team continuously, based on the changing market needs and competitor offers.
Requirements prioritization is critical to deliver higher ROI in Agile development where the team is delivering software in short bursts periodically. It is important to note that the business stakeholders have the ultimate authority to decide the priority of requirements. The prioritization technique would help them to tune the priority based on the factors that they are not aware of or might have overlooked.
Even though business wants to deliver entire scope now, certainly there are Constraints of budget, skills and cost. If the business delivers requirements incrementally, it can realize the value and get crucial feedback frequently to improve the system. The prioritization allows you to recalibrate what you want to deliver in each iteration which is just a few weeks away unlike a few months in the traditional model.
Effective Requirement Definition:
In Agile requirement, the definition does not mean to define the finest detail about everything. Instead, it believes in the philosophy that there is no point in creating detail requirement specification when there is no absolute certainty of requirement which is getting released to production.
Also, defining requirements late, just in time, provides the ability to do a course correction and learning from earlier development. This helps in reducing rework later.
Hence when defining requirements in the product backlog, the product owner can take the liberty of not defining the detailed requirement. In fact, it can be even a single line. However, as the requirements move from product backlog to sprint backlog, it should be detailed enough for the team to estimate size and effort, and break down the task.
One of the key practices used to validate requirements understanding, is to have UI (user interface) wireframes of the workflows attached to stories and looping product owner to avoid rework.
Another key practice is to identify the dependent requirements early. Like- Interfaces are to be identified at the start of sprint planning as this might impact testability wherein we may need to create a stub to test or consume 3rd party APIs to test it.
You need to ensure that as far as possible, the requirements are platform-independent. This used to provide flexibility for implementing them.
Role of Requirement Workshops:
For the large enterprise application, the requirements are often very large in nature. In order to break them into Epics and User Stories, the team has to spend huge time for every major release. To lower this effort, Requirement workshops are organized. Time-saving is the main purpose of requirement or discovery workshops.
Requirement workshops are carried out from a few hours to a few days depending on the size of the release. The outcome of these workshops is Epics and stories or which the stakeholders have enough clarity.
These workshops have stakeholders from even extended teams such as Tech Architect, Solution designers, IT Managers, Capacity managers and BAs (Business Analysts) to ensure teams are collectively aware of what they intend to complete and release,
In this workshop, requirements are prioritized, detailed out, estimated. Also, rough timelines are decided for spirit and release based or business needs. In case the work exceeds the timeline, voting or any other technique can be used to decide the feature that will give maximum value.
Drive Requirement Accuracy:
Requirements or work items should be detailed enough for the team to pick up and complete. Evolving requirement is part of Agile framework and hence, it is not mandatory to have all the requirements defined to every minor detail.
However, the requirements that are taken up for development should have enough clarity to help team estimate them to a satisfactory and agreeable level. The complex
The epic requirement should be broken down to sub epics until it is possible to define multiple short features/ stories for each one.
The requirement becomes accurate when it is smaller as it will have User unknowns, depending and associated risks.
Adding testable acceptance criteria in each requirement defined by business stakeholders, that clearly outline what is expected at the completion of the requirement, will help in a major way to increase requirement clarity.
Techniques and Practices for gathering requirements
User story:
The user story is one of the most popular and recommended techniques for writing requirements. The product backlog contains multiple stories, Epics and its prioritized as per business value regularly.
A user story is written in the perspective of the user and how it would help business. It must always capture acceptance test which should be testable and answer how the team would be able to claim the completion of the story.
Definition of Done:
Each story should have DONE criterion to consider the story for acceptance. A simple DONE criterion can be as-
- The story is developed and Unit tested
- Peer-reviewed and passes all unit tests
- QA Complete and no defect open.
- Acceptance criterion satisfied.
However, they can be fine-tuned based on team maturity. Team meetings which can happen in the mid of the sprint for an upcoming requirement can be a good way to understand the next sprint goals to ask questions.
The product owner can then come prepared to address all the queries before/during sprint planning. This would help the team to waste time in defining requirement in the actual planning meeting.
Even though User stories provide good enough way to capture requirement, the format prohibits getting details of all user interaction with sample data.
This is when techniques such as storyboarding or scenario sketching are used. Here the entire workflow of user interaction is captured along with the sample data.
3c’s for writing good user stories:
Ron Jeffries, the co-inventor of the user story practice and founder of XP, refers to three important components of a user story-
- Card
- Conversation
- Confirmations.
Otherwise known as 3Cs.
The terminology ‘card’ comes from XP world where the practice of writing requirements on index cards has flourished. The purpose of using cards for writing requirements was to keep it short and leave room for other ‘c’ (conversation) to get more details about the story.
The card provides a starting point for defining requirement and conversation brings required details. There may be more than one conversation needed to get enough clarity for the team. If the team is following cards, only the conversations summary must be recorded or the backside of the card with the date.
The third C is confirmation and nothing but Acceptance tests we discussed in the above. These tests provide ways for the development team to confirm if they are meeting the story card needs. Sometimes these can prove as excellent artefacts to be considered as part of documentation deliverables.
Most of the time, in the GDM model, where teams are working from multiple locations, the team use Agile lifecycle management tools like Rally, Mingle, Version One, Jira rather than physical index Cards.
In such cases, details of the conversation, discussion in planning or pre-planning should be added in the story details section with the date. Tracking is easier in these tools, without worrying about any Spillover.
INVEST Technique- Very popular technique while capturing requirements in agile
Bill wake author of ‘extreme Programming Explored’ has suggested that INVEST model which is widely used as a guideline to define stories in the Agile world. It is a simple technique to answer whether or not a user story is well-formed.
Independent: Stories should be as independent as possible. If there are dependencies between stories, it might lead to them not getting delivered due to another story. It also adds to problems while estimating the stories.
Negotiable: User stories provide a brief description of the functional details which should be negotiated in a conversation between the customer and development team.
Valuable to purchasers or Users: User stories should avoid including user interface assumption and technology assumption.
Estimable: Developers should be able to estimate the amount of time of a story will take to Code/develop.
Small: Stories should be small and concise. They should be easy to understand and estimate. It is better to have more number of short stories rather than having one large story.
Testable: Stories are not contractual obligations. The agreements should be documented by tests that demonstrate the correct development of a user story. Successfully passing the tests proves that a story has been successfully developed.
Requirements Prioritization Technique
prioritizing By Value The best way to capture requirements in agile:
In a typical enterprise application, there is a portfolio of hundreds of IT projects getting executed at the same time. Many of these IT projects are legacy applications running for years while few are created to address new market needs.
For such large enterprise application, realizing the business value can be very challenging and would often require a group of product owners or product Managers determining the value in term of tangible (first-mover advantage, unique offering) and intangible (performance, workflow, usability, improvements) benefits.
Ensure that large requirements are broken down in releasable features to realize the business value incrementally.
The factors that should be considered are value stream visualization, cost to build the feature vs efforts, flexibility, infrastructure cost, risk, skills, segment/audience to which it is targeted and their needs and also whether of would make it in the MMF (Minimum Marketable Feature) list.
Some requirements are essential to improve operations or for statutory compliance reasons and do not add business value, rather they are cost realization.
MMF (Minimum Marketable Feature): One of the leading way to capture requirements in agile
The team MMF comes from ‘Software by Numbers’ by Devine, Cleland Huang. In the Kanban world, the work priority or more important requirement are talked in terms of MMF.
With lean becoming popular in recent times, MMF was reoriented in terms of
- Minimum Viable Product (MVF)
- Minimum Viable Feature (MVF)
- Minimum Marketable Release (MMR).
The term Viable instead of ‘Marketable’ is used because, for a major release of an enterprise, the business value is not always based on market forces but also as what’s feasible and if teams on the right track to achieve the differentiators.
Similarly, MMC is clearly focused on the set of features that needs to be clubbed and released together to gain business value.
By choosing to prioritize based on MMF or MVF, the team focuses on completing smallest functionality of real importance to business and end-users, rather than releasing theme or on an epic which may not directly lead to delivering most important need.
The MosCow law – limited use but useful to capture requirements in agile:
The MosCow has first coined in CASE (Computer-Aided Software Engineering) method fast-track which was a RAD (Rapid Application Development) approach.
Later it became part of the Dynamic Systems Development Method (DSDM) consortium. It is a helpful technique to determine which requirement should be delivered first and is based on categorizing requirements based on attributes given below-
Must-Have– Must have are the requirements that can not be negotiated and if not delivered, delivery would be considered a failure. Must have requirements should fall under MMF for sure.
It is important to note the business stakeholders and vendors may falsely believe everything as MUST, typically, in Fix Price (FP) projects but it probably is just a perception and not reality.
Should Have: Important, but may not be required immediately.
Could Have: Often they are nice to have features that generally create intangible benefits such as clients satisfaction rather than increasing real business volume.
Won’t Have: Least priority at that point of time.
Cost of Delay(COD)- Advanced way to capture requirements in agile
COD is simply the impact of not completing a user story or feature to business. This is one of the basic prioritization techniques. It can be used with the Kanban method to effectively prioritized requirements that have more value over others because of cost of non-completion.
COD or Opportunity Cost is many times represented in graphical form as a line showing the relationship between impact vs time. Apparently steeper the angle of the line, worse is the impact over time.
Impact of COD can be losing first-mover advantage (Competition risk), Compliance risk or identity crisis in the crowded market without the differentiator.
There are four pillars for COD-
- Emergency or high business impact and high risk-prone.
- Fixed schedule (where, if you deliver after schedule, you never incur heavy cost like policy change).
- General or standard (impact with medium risk).
- An investment where the business is investing to make the product better (a wish list item).
Certainty– It is a well-known fact that Certainty helps in selecting requirements. Uncertainty about end-user needs or methodical solution will put the same on the backburner.
Certainty helps in fast-tracking the decision process of business stakeholders whereas uncertainties posses a major risk or moving ahead even if the requirement has more weightage while prioritizing the requirements.
Feasibility: Even if requirements are critical, the team needs to ensure that they understand the feasibility of the requirements. Feasibility can be gauged based on the cost/benefit analysis (CBA) methods as well as understanding technical complexity.
Buy a Feature– Buy a feature is a simple technique for prioritizing the stories for a release or a sprint. In this method, first, the story is estimated in story points or T-shirt size estimation and then, each team member is supplied with a limited virtual budget to buy the feature/story they would like to see completed and released early.
It is believed that the collective wisdom of the crowd is better than the decision of an individual.
Here the idea is to bring the collective flavour of Agile to decide the release plan. When people are contained by the budget, they start thinking, discussing need and benefit and even convince or negotiate with fellow team members or even product owner for selecting practical feature ahead of others.
The bought work items thus represent shared priorities. To bring in more consistency or normally, it can be executed multiple times. This ensures that the most critical work items are taken up for development.
AHP (Cost/Value Approach) An updated way to capture requirements in agile
Analytical Hierarchical Process is a structured technique for decision making. Many organization across the world use this model to compare and rank attributes.
It provides the ability to do a relative comparison between a pair in a grid-like a format. The priority itself can be based on multiple factors but the major ones would obviously be of value to business and efforts to develop.
So, in this pair of requirements can be compared against each other and more important ones can be determined by the individual. The same can be done by the entire group and then collectively, they can see their choice Vs group’s collective choice to decide which requirement is of higher priority to the group.
However, this does not work well when we have to deal with a large number of requirements and compare them against each other.
Planning Game my favourite to capture requirements in agile:
Planning Game from XP is another (simple and effective) technique or way to prioritize requirements. It is based on two attributes –
- The business value of the requirement for customer
- The cost (development effort).
In XP, this game is played as part of planning meetings and goes on till the time all requirements are prioritized. Customer (business stakeholders) will present the requirements based on the value and efforts.
It is a balancing act between what customer wants vs. at what cost.
Bubble sorting another approach to capture requirements in agile:
On this technique, you start at the top and compare the items and flip them if they are not in the correct sorting order. This will go on till you are not done with the entire set of the list by which time you would have all the items sorted. This is the simplest mathematical technique to put a list in the away in order.
Now if you map the elements with the requirements and apply this technique, you can certainly order them which is prioritization.
100 point Method a nice approach to capture requirements in agile:
The 100 point method is a prioritization technique based on the group wisdom (Cumulative Voting or Dot Voting) which wins over individual knowledge and depth.
In this, each member within the group is given 100 points which they can distribute as votes across the requirements to be prioritized.
The team member can put all his/her points on a single item or not necessarily put a single point on multiple items. The denser the requirement the higher priority it would be.
All requirements with the same point (vote) can be compared against each other to decide the final order.
Other requirements definition technique while capture requirements in agile
System perspective:
This includes thinking about requirements from the different user profiles who would interact with the system including users directly getting impacted, user roles who might get influenced and the restraints under which the system needs to perform.
Conversation:
Teams should conduct an interactive conversation with the product owner and ask open-ended questions to determine expected behaviour while refining the requirements.
Use Case:
Use cases might be a nice way to capture the expected and exceptional behaviour of the system.
Scenario:
The scenario can quickly outline expectations in business terms without getting into details and can be just the right approach for the detailed requirement in the Agile framework.
Any progressive modification in the requirement after iteration committed should result in updating the master requirement definition in case of minor change and a new sub-feature in case of major change’
Kano model:
Kano model is another prioritization method which strives to fulfil requirements and please customers. This model features four components:-
- Must-haves are the elements without which the product can not be shipped.
- Dis-satisfiers are things the product must not include.
- Satisfier includes requirements where the more you have the better the product is perceived. (like a checklist, each features adds incremental value.)
- Delighters take the product towards not just meeting the requirements but to boost client satisfaction and recommendation.
Ref:
Agile handbook.
Conclusion
In this post, I tried to explain the actual software industry-specific definitions of requirements. I have explained various ways to capture the requirements while moving forward in the Agile way of software development and test.
If you enjoyed this post, please share it on social media ?“What am I missing here? Let me know in the comments and I’ll add it in!”
