In layman’s terms, a product can be considered successful only when a huge number of people use it and the owner can earn a good profit by selling it in the market. The “power” of a product can be judged by the kind of features it supports and how useful those features are to end users. Therefore, it is important to capture the requirements of end users in a systematic and organized manner in your product, and determine how important they are. The business value in Agile is indicated by how much important a feature, or a “user story” is from the client or end user’s perspective.
Not all features are used frequently by end users
Users don’t always use each and every feature offered by a tool or automated process. As per observations:
- 57% of the features are never used
- 19% are rarely used
- 16% are used sometimes
- 13% of the features are used quite often
- 7% of the features are used on a regular basis
Agile focuses more on the development of these frequently used 7% of the features which carry more business value.
Doing it the traditional way
Traditional development methods follow a sequential (non-iterative) design process involving conception, initiation, analysis, design, construction, testing, production/implementation and maintenance stages. Requirements are gathered from the client, project owners, stakeholders, end users and other sources. These requirements are documented in the requirements phase at the start of the project. Once defined and documented, the requirements cannot be changed in subsequent stages. Therefore, in Waterfall methods, once end-user requirements are captured in the project new requirements can’t be added later on. Moreover once documented, the requirements cannot be changed or updated in subsequent stages even if stakeholders or end users want modifications in existing functionality. So if you’re following Waterfall methods you can capture end-user requirements only once in your project when it starts.
How Agile does it
It’s not very difficult to capture client-centric requirements in Agile:
1. Get valuable ideas and feedback from client, end users and various other sources
Based upon the product vision shared by the client, the Agile team invites the stakeholders, technical team, end users, marketing and sales team, and management personnel to brainstorming sessions with an objective to identify market requirements and spot end-user needs. Data is also gathered from various other channels such as usability testing, product usage data, emails, forums and more if possible.
2. List the ideas in the form of user stories in the product backlog
Ideas and suggestions collected from people and other sources are thought over and shortlisted to include only valuable suggestions which have a certain importance in terms of how useful they are to people using the product. The requirements are documented using an “As an, I want to, So that ” format to specify the role (Who wants the feature or functionality), proposed activity (to do what) and the result or objective (to achieve what). This particular form of documenting the client/end user requirements is known as “user story” creation. A common list of all features and functionality required to build the product is prepared. This list is known as the “product backlog”.
3. Detail each user story and prioritize its importance
It can be difficult to specify the technical aspects and the particulars of each and every user story at the time of its creation. The reasons could be many. At times teams might feel a particular feature is important and should be included in the backlog but may need further participation from end users to get the required details. In such cases, a user story is created for the particular feature and included in the backlog but its details may be kept blank. Later on, when proper details are made available to the team, it updates the particular story by filling up the blanks with relevant info.
Agile focuses upon timed and sustained delivery of business value at the end of each product incremental cycle. Important stories having high business values are placed at the top of the product backlog while less important ones are arranged below them. Stories in the bottom have the least value. At the beginning of each new development cycle, few valuable stories are collected from the top of the backlog and made ready for the upcoming sprint. Stories are always collected from the top to ensure that maximum value is delivered to the client from each sprint.
Requirement Gathering In Traditional Method Vs. Agile
Using the tool
1. Creating user stories for capturing requirements
Requirements in the form of user stories can be added dynamically to the product backlog:
Alternately, you can also add the stories while planning the sprint:
… or even while using the Scrum board:
To find out more about adding stories visit:
2. Detailing the stories with relevant information
User stories form the base of all development activity. Therefore, for teams to develop meaningful and useful features, each story should be properly described and detailed by the client, end user or the person who requests the functionality. The value of a story depends upon how well its acceptance criteria is stated. The acceptance criteria is a set of statements with each state having a clear pass/fail result. The statements specify both functional and non-functional requirements. To find out more how to state the acceptance tests please visit:
3. Prioritizing stories as per their importance and business value
The value of a project i.e. its ROI depends a lot on how stories are estimated and prioritized in the product backlog. To deliver high-value stories on a consistent basis, it is important to organize the backlog in a manner such that important and valuable stories can be found on the top and easily picked up for development purposes. To understand how to rearrange stories as per their importance please visit:
Transitioning to Agile processes
There are many benefits of Agile. Development teams can become highly productive using Agile processes. However, teams and newbies migrating to Agile should typically expect the following:
- Reading about agile just isn’t enough. Agile can be easy to read and understand, but when it comes to implementing Agile in real life, teams often struggle and don’t get proper results in the beginning. It is important to prepare for the transition and get proper Agile coaching so positive benefits can be availed.
- Each and every member in the team, whether it be a developer, tester, database administrator, technical writer or a system architect, it is important to try and get involved with the project as early as its inception so the entire team can become familiar with the product backlog (features list) and iteration planning (sprints and releases) to keep pace with work and project deliverables.
- Unlike traditional approaches, stories in Agile get developed quickly and made shippable within a short time during the iteration or sprint cycle which generally last one or two weeks. Teams have to remain focused and time-bound.
- The feedback cycle is quick in Agile. The client, stakeholders or end users can submit new requirements even while the team is busy developing the stories. Teams have to develop a mindset to adapt to changes as and when they occur.
- In Agile nothing happens by accident. Teams have to plan work and perform the ceremonies in a proper manner so the process can become streamlined and business value can be delivered on a consistent basis at the end of each product incremental cycle. Teams have to work hard to create an Agile environment if they wish to become Agile.
End-user requirements are very important for any business since they define the deliverables and scope of the product or services offered by the organization. While Waterfall processes are simple to understand and follow, they fail to adapt to changing end-user requirements and market-induced conditions as they follow a linear-sequential life cycle model. Businesses have to transition to Agile at some instance of time if they’re to remain competitive and sustain a good growth in the market they are in. Organizations desiring to realize the time, quality, and cost benefits of agile project management have to prepare for change management and get trained in Agile processes to reap its benefits.