- Agile, DevOps and software development methodologies
How to write a business requirements document in Agile
Agile doesn't rely on lengthy documentation or a control board, but it does need business requirements. here's how to work business requirements into epics and user stories..
- Diane Hoffman, Intelopment Group LLC
Customers want what they pay for. Businesses want satisfied customers. This simple mantra fits into all elements...
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
You forgot to provide an Email Address.
This email address doesn’t appear to be valid.
This email address is already registered. Please log in .
You have exceeded the maximum character limit.
Please provide a Corporate Email Address.
Please check the box if you want to proceed.
- I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.
of the business world.
From an IT perspective, organizations expect software they purchase to work in the way it's promised from the company they bought it from. And the business expects that its product will result in a satisfied customer.
An IT organization must have clear and comprehensive documentation that sums up -- in business terms -- what it should deliver to a customer. The team can fulfill that demand with a business requirements document.
Let's evaluate the role of a business requirements document (BRD), how Agile and non-Agile teams convert requirements into working code and how to determine if the team fulfilled business requirements.
How a BRD sets expectations
A BRD describes the business purpose for a project. It defines how to produce the product, including its objective, how it works and the client's intended use. With a BRD, a business can assess potential cost factors and constraints, and a timeline or schedule for the software project. A BRD represents a basic contract between the customer and the vendor; it outlines the expectations and deliverables for the project. Additionally, it sets the standards for project success.
Before any IT organization builds an application for customers or business stakeholders, it should understand how to create a detailed BRD, particularly for Agile teams to use.
A BRD template for Agile teams
Business requirements documents can take on various structures. However, a successful Agile BRD should contain these key 10 components:
- project overview;
- success factors;
- project scope;
- stakeholder identification;
- business requirements;
- scope of the solution;
- functional requirements (optional);
- project constraints (such as schedule and budget);
- quality control measures; and
- schedule, timeline and deadlines.
How functional and business requirements differ
Although the terms are often used interchangeably, business requirements are not the same as the functional requirements for a project. The business requirements describe the deliverables customers need, but not how to accomplish them.
The functional requirements cover how to meet customer expectations with a software product. There can be separate software requirements documentation for development projects or a functional requirements section in the BRD. These functional requirements detail how a system should operate to fulfill the business requirements.
How to use BRDs in Agile development
In Agile, the product owner or customer representative typically defines product features. The features are considered an epic in Agile, and these epics encompass everything defined in the BRD. The Agile project manager works with the product owner to translate the BRD into a series of epics that define the product. These two then translate features to user stories . Here, developers meet the functional requirements to fulfill the business requirements.
A user story briefly describes something of value to a target user -- or customer. Here's an example of the user story format:
"As a < type of user/role >, I < want/desire to >, so that < some reason/benefit >."
The user story also includes acceptance criteria, which describe what the function must achieve, and how developers can determine if the user story succeeded or failed.
Many development groups further break down user stories into tasks and/or sub-tasks that focus on different components of the system. For example, tasks cover work on the UI, the back end or database that the development team needs to finish to complete the story.
How to manage BRD changes
Many non-Agile teams use a well-defined configuration management process to track a project's requirements. This process uses automated requirements management tools to cross-reference each requirement developers use to create a traceability matrix. This matrix helps confirm that the development team addressed each requirement and that development only creates artifacts tied to requirements. Management of the documents and requirements is the responsibility of a configuration control board.
In Agile, the team maintains the relationship between the top-level product feature and the lower-level development tasks via a parent/child relationship. The Agile project manager and product owner tie all user stories to their parent epic, and all tasks and sub-tasks connect to their parent user story. This inherent relationship and flow allow the Agile project manager to easily track its progress. The setup also allows the product owner to manage or reorder work based on initial and changing priorities .
How to react to business requirement changes
Customers can make requests for changes (RFCs) and vendors can accordingly write and approve revised business requirements. However, RFCs can mean additional costs and longer timelines for development teams. Also, managing these changes is different in Agile and non-Agile development.
Teams in Waterfall and other development styles often actively control prospective changes to business requirements documents via the change control board. This body preapproves requested changes and sometimes also confirms that approved changes were made based on customers' specifications.
Changes in Agile take form as either additional epics or additional user stories based on the scope of the RFC. A control board doesn't exist in Agile teams, and the product owner -- who works in conjunction with the development team -- fulfills that role. As the client or development stakeholders agree on feature changes, the Agile team writes new user stories that the product owner must prioritize in the backlog for developers. Afterwards, the development team should review those stories in backlog grooming sessions and create any necessary tasks. The BRD traceability matrix is inherent in the parent/child relationship between epics and stories.
How to measure completion of business requirements
Agile teams measure success at each level in the development process.
At the release level, the product owner continuously makes tradeoffs in scope, date, budget and quality as a stream of economically important information arrives during product development. Ultimately, Agile teams can measure success at this level by the on-time delivery of product features that the product owner committed to deliver.
To get to that delivery, the Agile team must accomplish the tasks, complete the user stories and acceptance test each feature. At the task level, unit tests on code verify that it meets the threshold necessary to commit. At the user story level, team members use acceptance criteria to determine if they satisfied the specific aspect of the feature. When developers complete all the user stories successfully, the team can then perform user acceptance testing on the epic or feature.
How to tame ever-changing requirements in software development
How to document software requirements without hating your job
7 techniques for better Agile requirements gathering
Dig Deeper on Agile, DevOps and software development methodologies
6 strategies for better software project portfolio management
How to choose exactly the right data story for your audience
What are the types of requirements in software engineering?
The 7 user story guidelines every Agile developer should know
AWS Compute Optimizer and Cost Explorer monitor, analyze and optimize your cloud costs. Compare the two tools to choose which is ...
Azure management groups, subscriptions, resource groups and resources are not mutually exclusive. Businesses can -- and often do ...
Amazon CodeGuru reviews code and suggests improvements to users looking to make their code more efficient as well as optimize ...
Open banking has made financial transactions easier and more secure for those with multiple banking accounts; however, ...
REST may be a somewhat non-negotiable standard in web API development, but has it fostered overreliance? Learn why other design ...
Developers can use Microsoft Azure Logic Apps to build, deploy and connect scalable cloud-based workflows. Learn how it measures ...
While some think DevOps has run its course, others say it's just maturing and evolving into what organizations need -- which, for...
A PowerShell performance monitoring script defines and keeps track of system metrics. Learn to set up and query performance ...
Looking to streamline network management for Kubernetes clusters? Learn when and how to use CNI plugins, then walk through the ...
Has there ever been a better time to be a Java programmer? From new Spring releases to active JUGs, the Java platform is ...
Software developers can find good remote programming jobs, but some job offers are too good to be true. Follow these tips to spot...
Many organizations struggle to manage their vast collection of AWS accounts, but Control Tower can help. The service automates ...
There are several important variables within the Amazon EKS pricing model. Dig into the numbers to ensure you deploy the service ...
AWS users face a choice when deploying Kubernetes: run it themselves on EC2 or let Amazon do the heavy lifting with EKS. See ...
Ask a question
- Jira Service Desk Jira Service Management
- Confluence Confluence
- Trello Trello
- Jira Work Management
- Sourcetree Sourcetree
- Opsgenie Opsgenie
- Technical support
Atlassian Community Events
- Atlassian University
- Feedback Forum Announcements
- Off-topic Off-topic
- groups-icon Welcome Center
- groups-icon Featured Groups
- groups-icon Product Groups
- groups-icon Regional Groups
- groups-icon Industry Groups
- groups-icon Community Groups
Earn badges and make progress
You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Participate in fun challenges
Challenges come and go, but your rewards stay with you. Do more to earn more!
Gift kudos to your peers
What goes around comes around! Share the love by gifting kudos to your peers.
Rise up in the ranks
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Come for the products, stay for the community
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
- Jira Software
The art of writing good requirements
Was this helpful?
About this author
Atlassian Consultant, Product Owner
124 accepted answers
1,033 total posts
- +52 more...
- Community Guidelines
- © 2023 Atlassian
- Contact Sales
- Business strategy |
- Business requirements document template ...
Business requirements document template: 7 key components, with examples
A business requirements document (BRD) is a report detailing everything a new project requires for success. There are seven key components of a BRD template, which serve to provide clarity and context for stakeholders. In this piece, learn how a BRD template can increase your chances for project success.
Every project has moving parts, and if you want a successful project outcome, you’ll need all those parts to come together at the right time and place. Think about putting a puzzle together; the secret to solving it is to look at the picture on the front of the puzzle box as you navigate your way through it.
What is a business requirements document (BRD)?
A business requirements document is a report detailing everything a new project requires for success. This document outlines project objectives , what’s expected throughout the project lifecycle, and what’s required to accomplish the project.
The seven components of a BRD are:
By outlining each of these sections, anyone who reads your business requirements document should clearly understand what your project is, what you hope to achieve, and how you plan to achieve it.
What should a business requirements document include?
Your business requirements document template should provide detail about your project, but it should also be concise. The goal of the BRD is to give readers the most information in the least amount of words.
Many people may read a BRD, including stakeholders involved in the project, executives you need approval from, and clients influenced by the end results. Learn more about each component to include in your template below.
1. Executive summary
The executive summary is a high-level statement outlining what your project is and its purpose. Those who don’t have time to read the BRD in its entirety should understand what you plan to accomplish by reading your executive summary.
Even though your executive summary is the first thing in your BRD, you should actually only write it after writing the other sections. That way, you can review everything and ensure you’ve created a comprehensive opening statement.
2. Project objectives
Your project objectives are the business goals you want to achieve by putting your project into action. It’s important to state your project objectives before kicking off any work so you can use them to measure your progress.
List your project objectives as SMART goals to ensure that they’re:
Measuring your project objectives can help determine whether you need to adjust your workflow to better meet your goals. For example, if one of your objectives was to increase your customer base by 10% by the end of the quarter, you can look at your numbers when the quarter ends and clearly see whether you hit your goal or not. You can then look at the actions you took along the way and determine the reasons why you may have fallen short.
3. Project scope
Your project scope communicates the boundaries of your project on your business requirements document. By defining your project scope, you’ll keep everyone on the same page and prevent scope creep , which is when your project expands outside of the boundaries you set for it and becomes hard to control.
Details to outline in your project scope include:
You can also make a list of project exclusions—or things you specifically want to leave out of your project—like business processes or risky strategies you want others to avoid when they’re working on the project.
4. Business requirements
The business requirements are the meat of your BRD template. In this section, you’ll list the actions required to accomplish your project. Depending on the project complexity, this list may be just a few items or it may be extensive.
In addition to listing your requirements and describing them, rank them by priority and assign each item a level of importance based on how critical they are. This will help others understand which requirements they need to complete first.
If one of your requirements is to code a website, you may assign this task as a number one priority. You can also label this task as highly critical because, without coding your website, you won’t have a foundation to complete other business requirements.
5. Key stakeholders
Project stakeholders include anyone with an interest in your project. These are likely the people who will read your BRD template to understand what the project is about. Your key stakeholders may be:
Team members working on the project
Project managers leading the project
Executives approving the project
Clients influenced by the finished project
In this section, list the names and job roles of each stakeholder and describe their duty in relation to the project. This section will give everyone clarity on who else is involved and can improve team communication .
6. Project constraints
You likely presented an overview of your project constraints within your project scope, but here, you’ll explain these boundaries in more detail. When the reader reviews this section, they should see the shape of the project and its limits.
Project constraints may include:
Project constraints help stakeholders visualize the complexity of the project and how easy it will be to achieve project objectives. Anyone involved in the project should first review the project constraints.
7. Cost-benefit analysis
Ending your business requirements document with a cost-benefit analysis is a strategic move. If you’re using your BRD to get approval for your project, this section may be the deciding factor. Clients and executives care about the project objective, but if you can’t prove that you’ll make a profit, then all is lost.
To create a cost-benefit analysis:
Describe all the costs associated with your project
Explain the associated benefits
Write the total expected cost of your project
Estimate the expected ROI by subtracting your estimated costs from your estimated income
Business requirements document template (and example)
Here, you’ll see an example of a business requirements document template. This example is for a tech company’s initiative to start a marketing blog. In the document, the project manager explains what the project is and its purpose. She also outlines the project objectives and the project scope to avoid the risk of scope creep.
As the BRD continues, the project manager lists the business requirements—the actions needed to complete the project. Other listed items are the stakeholders involved in the project, the project constraints, and the cost-benefit analysis.
If you want to use a business requirements document template for your own project, use our free template below.
What is the difference between business requirements and functional requirements?
You’ll often hear functional requirements come up when discussing business requirements, but it’s important to know the difference between the two. A business requirements document discusses what your project requirements are. This document offers a high-level view and gives stakeholders an overview of the project in its entirety.
A functional requirements document (FRD) provides a detailed description of how to perform specific tasks within the project. Think of these documents like playing a board game; the BRD is the box, explaining the game and convincing you to buy it. The FRD, on the other hand, are the instructions teaching you how to play the game.
Besides functional requirements, there are:
User requirements: These requirements are more detailed than the BRD, and they explain what the user can do with the finished deliverables .
Product requirements: These requirements are more detailed than both business and user requirements. Product requirements explain the finished project’s purpose and features. This document is a guide for teams when building and marketing the product.
Non-functional requirements: These requirements are the most detailed type of requirements—equally detailed to functional requirements. They explain how the project should operate and the finished project’s intended user experience.
Share requirements through project management tools
Whether you’re creating a business requirements document or something more detailed, the best way to share information with stakeholders is through one streamlined tool.
With project management tools, you can prioritize business objectives and ensure nothing falls through the cracks. Use Asana to streamline team communication and make hitting project milestones easier.
How to pitch project management software: A complete guide
How to create a CRM strategy: 6 steps (with examples)
Level up your marketing with a perceptual map (with template)
Business process analysis (BPA) explained
- Jira Software
- Jira Work Management
- Jira Service Management
- Atlassian Access
- Company News
- Continuous Delivery
- Inside Atlassian
- IT Service Management
- Work Management
A Guide To Agile Requirements Documentation
This is the second blog of a two-part blog series about requirements documentation for agile teams. Last blog post we looked at walking the documentation tightrope in an agile world – the challenges faced by teams switching over from a “traditional” product requirements document to other techniques used to define problems. We reminded ourselves that writing a requirements document should be considered as just one of many different ways we can define customer problems.
So you’ve discussed a set of user stories with your engineer and designer. Gone back and forth, had a few whiteboard sessions and concluded there are a few more dimensions you need to consider for this feature that you are working on. You need to flesh out some assumptions you’re making, think deeper about how this fits in the overall scheme of things and keep track of all the open questions you need to answer. What next?
What does requirements on a single page look like? For all the details you can look at the requirements Blueprint we shipped in Confluence 5.1, which has been modelled from what we see many agile teams doing as well as from how we do requirements internally at Atlassian.
The rough outline of the structure is as follows:
1. Define document properties Some brief metadata about the document (Such things as the owner, stakeholders, status, target release etc…). This helps get everyone on the same page in terms of who is responsible for what and communicating our target release goals. We use these properties to also report and quickly access previous requirements on an index page showing all the requirements:
2. Communicate the overall goals Be short and straight to the point to explain what you are trying to achieve.
3. Background and strategic fit Why are we doing this? How does this fit into our overall vision of our product, company or epic?
4. Assumptions List the technical, business or user assumptions you might be making. This is very helpful in providing context as someone reads your user stories.
5. User Stories We list the user stories involved here typically in a tabular format. Where possible, try to include context. Link to customer interviews, take screenshots of what you’ve seen. Embed audio or multimedia content of your customers. Provide as much detail as you need to tell the story. How will we know we’ve succeeded? We often note success metrics for each story in this section as well.
6. User interaction and design Quite often filled out after we discuss the problems and flesh them out, we keep the designs embedded or linked from the same page.
7. Questions As we are thinking about our problems, we often uncover new questions that need answering. So we typically have a table of the “things we need to decide on or do further research”. This table typically grows towards the definition phase and as we start implementing we find ourselves coming back to it and updating it as decisions are made.
8. Not doing This is often very helpful in getting your team focused. Write down a list of related things which may be out-of-scope or you might look at in a later date. I often find this list keeps on growing as you explore the problems in depth. You realise there are many orthogonal problems which you could solve, but you need to stay focused. I’ve spoken to quite a few customers that have re-iterated the importance of this list in terms of getting everyone on the same page. This helps reduce any ambiguity and gives the team greater focus as well as providing management greater predictability of what is in and out.
Why bother? What value do I or my team get out of something like this? If you are to take away anything from this blog, understand the “why” – the not “what”. The “what” is the easy part to create, the “why” will help you explore what is best for your team. Here are the benefits and challenges we’ve observed with this approach:
1. One page, one source, one problem Keeping it simple. The requirements page becomes the “landing page” for everything related to the set of problems within a particular epic. Having something that is the central go-to location saves your team members time in accessing this information and gives them a concise view.
2. A page enables you to be agile One of the awesome things about using a simple page to collaborate on verses a dedicated requirements management tool is that you can be agile about your documentation! You don’t have to follow a format every time – do what you need, when you need it and be agile about it. In fact, I encourage you to customise the Requirements Blueprint as you learn what works for your team so you can model your processes easily. Chop and change as required.
3. Dive in for context and detail We often forget how powerful a simple link can be. We embed a lot of links within our requirements landing page. It helps abstract out the complexity and progressively disclose the information as it is needed to the reader. Linking detailed resources my included such things as:
- Customer interviews for background, validation or further context for the feature
- Pages or blogs where similar ideas were proposed
- Previous discussion or technical documentation and diagrams
- Videos of product demos or other related content from external sources
4. Living Stories: Stay updated, track and report on progress I see a lot of customers do this as well. Once the stories have been roughly thought out – we often use the Jira integration features in Confluence to link the two. From the page you can easily create your backlog stories . These are automatically embedded with two-way syncing from Jira. So you instantly get progress reports of how the story is tracking with your dev team, right from your requirements landing page. Learn more .
5. Use your collective team and organisational wisdom Especially if you are in a large organisation – documenting requirements Confluence makes it easy for other people in different teams to contribute and make suggestions. In the Confluence team, I’ve been amazed at the amount of times someone else from another team jumps into the conversation with a comment providing great feedback, suggestions, or lessons learnt from similar projects. It really does help a large organisation feel like a small team.
6. Make them dynamic and engaging Use diagramming tools like Gliffy or Balsamiq to better communicate the problems to your team or embed external images, videos and dynamic content.
7. Collaborate! The most important aspect of all this is getting everyone involved. Never write a requirements document by yourself you should always have a developer with you and write it together. Share the page with the team and get feedback. Comment, ask questions, encourage others to contribute with thoughts and ideas. This is also a huge asset for a distributed team .
With every approach there are challenges. Here there are two main challenges we’ve experienced and observed from customers as well:
1. Documentation can go stale What happens when you implement a story and get feedback and then modify the solution? Does someone go back and update Confluence with the final implementation? This is a general challenge with any type of documentation – It’s always worth questioning the value of this for your organisation. Talk to your team about what you would do in a scenario like this.
2. Culture of open collaboration “What can I do to encourage people to comment?”, “How can I encourage people to write more specs and stories on Confluence?”. This is really a tough one to crack and really comes back down to various wiki adoption techniques in your organisation. There are plenty of resources to help you here . There maybe cultural issues you might need to look at as well.
Give it a try
Last post, we looked at the different techniques you can use to define customer problems . In this blog, we dived into requirements documentation on a page. I hope this gives you some insights for how we, and many of our agile customers define product requirements in an agile world. To help you get started we’ve shipped the Requirements Blueprint in Confluence 5.1. Try it and let us know what you think!
The most important thing here to remember is: You shouldn’t stick to this method every time. Be agile. Scott Ambler puts it well when he says
“…by understanding the needs of your customers you will be able to deliver succinct and sufficient documentation…” – Scott Ambler, Best Practices for Agile Documentation ).
I’d love to hear form you: Are there other techniques you’ve deployed to define customer problems with your teams? What works? What doesn’t?
P.S. We’re hiring! Has this post got you interested in what we do Product Management at Atlassian? Interested in joining our team? We’ve got plenty of open product positions right now. Why not join us on our quest to enable teams to build great software!
For more, visit atlassian.com/agile . Or follow @ChetRong on Twitter! (Just don’t follow his advice.)
Advice, stories, and expertise about work life today.
- Contact sales
- Start free trial
How to Write a Business Requirements Document (BRD)
It’s easy to get lost in the weeds when you’re managing a project. There are day-to-day operations that the project manager obsesses over, but they also need to see the big picture. That’s why a business requirements document is so important.
To prove this point, let’s define what a business requirements document (BRD) is and what its components are. Plus, we’ll give you tips on how to write a better one before showing how project management software can make the process even more efficient.
What Is a Business Requirements Document?
A business requirements document offers an overview of what a business does and why it needs the project deliverable to be undertaken. It outlines the business solutions for project requirements that are necessary for the project to deliver value and becomes the foundation of the project’s life cycle.
The business requirements document highlights what the end result of the project should be. When a change request is introduced to the project, the business requirements document must be revised to reflect this change.
The main purpose of a BRD is to show what the system will look like from a business perspective. It includes both the business solution and the technical solution to the project. The business requirements document helps answer the question of what is needed for the business. It also answers how the project will be delivered and contains a prioritized list of features and business requirements that the delivered software, product or service must provide.
Think of the business requirements document as the defined steps you should follow to reach a result that serves both the customers and stakeholders for the delivered product, system or service. The project team is involved in this process to help determine how to implement the delivery of the project and fulfill what the business needs. Stakeholders are also involved and must agree on the plan before it’s implemented.
To accomplish this, you’ll need project management software that can organize tasks and connect the entire project team. ProjectManager is online project management software that delivers real-time data across multiple project views that lets everyone work how they want. Our interactive Gantt chart can be shared with teams and stakeholders as tasks are organized on a timeline. You can link dependent tasks, add milestones and filter for the critical path. Then, set a baseline and track your business requirements document in real time over the life cycle of the project. Get started with ProjectManager today for free.
Business Requirements vs. Functional Requirements
It’s common to confuse business requirements with functional requirements. They’re both requirements, but they serve different purposes. To review, business requirements explain the final results of a business goal in the project and why the organization should initiate that project.
A business requirement isn’t about offering or proposing a solution, only defining the task at hand. This includes defining the short and long-term goals, the company vision and the scope of the business problem.
On the other hand, the functional requirement is about how a system needs to operate in order to achieve its business goal. It proposes subjective solutions based on the organization’s strengths and limitations as well as being technically focused. A functional requirement is also presented with a use case.
It’s not always easy to tell the difference between a business requirement and a functional requirement. Project activities can be both a business requirement and a functional requirement or even neither.
Related: Free Requirements Gathering Template for Word
What Should Be Included in a BRD?
Why should you create a business requirements document? It reduces the chances that your project will fail due to misalignment with business requirements and connects the organization’s business goals with the project. It brings stakeholders and the team together and saves costs that accrue due to change requests, training, etc.
You’ll want to create a business requirement document, and even though it’s an involved process, it can be broken down into seven key steps. They are as followed.
1. Executive Summary
To begin, you’ll need to create an executive summary that provides an overview of the organization and the challenges facing the business. You’ll explain the issues and what the organization is trying to achieve to ensure everyone is on the same page. This section should be short, like an elevator pitch, summarizing the rest of the business requirements document.
2. Project Objectives
After summarizing the issue you plan to address in the project, you’ll want to clearly define the project’s objective . This helps define the project phases, creates a way to identify solutions for the requirements of the business and the customer, gains consensus from stakeholders and the project team and describes how you arrived at the objectives.
3. Project Scope
The project scope should define in detail what is covered in the project and what would make it run out of scope. This creates a clear boundary for the project and allows stakeholders and teams to agree on the business goals and high-level outcomes. Note what problems are being addressed, the boundaries for implementing the project and the expected return on investment (ROI).
4. Business Requirements
Here you’ll want to list the business requirements or critical activities that must be completed to meet the organization’s objectives. These business requirements should meet both stakeholder and customer needs. This can include a process that must be completed, a piece of data that is needed for the process or a business rule that governs that process and data.
5. Key Stakeholders
Now you’ll want to identify and list the key stakeholders in the project. Once you have that list, assign roles and responsibilities to each. These might be people outside of your department so you should define their role in the success of the project. This information needs to be distributed in order for everyone to know what’s expected of them in the project. You can even use this section to assign tasks.
6. Project Constraints
At this point, you’ll want to explore the project constraints . Define the limitations of the project and share those with the project team so they know of any obstacles earlier than later. In order for them to clear those hurdles, you’ll want to provide any necessary training or allocate resources to help the project stay on track.
7. Cost-Benefit Analysis
You’ll also want to do a cost-benefit analysis to determine if the costs associated with the project are worth the benefits you’ll get. This requires first determining the associated costs of the project, such as upfront development costs, unexpected costs, future operating costs and tangible and intangible costs. You’ll also need to figure out what benefits derive from the project.
3 Key Tips to Write a Business Requirements Document
As noted, the best way to begin writing a business requirements document is to meet with your stakeholders and team to get a clear picture of their expectations. But that’s only the start. There are many other best practices for writing a BRD. Here are a few.
1. Start With Thorough Requirements Gathering
Requirements gathering is the process of identifying all requirements necessary for the project. That means everything from the start of the project to the end of the project. You’ll want to address the length of the project, who will be involved and what risks are possible.
2. Differentiate Between Business Requirements and Functional Requirements
Remember, business requirements are what needs to be done, such as the project goals, and why that’s important for the organization. Functional requirements are how the processes, be they a system or person, need to work in order to achieve the project goals.
3. Use a Stakeholder Matrix
An important aspect of any business requirements document is identifying stakeholders . In fact, this should be done early in the process and a stakeholder matrix can help you analyze those stakeholders. It helps you understand the needs and expectations of your stakeholder in terms of their power or influence and the level of interest in your project.
ProjectManager Helps You Track Business Requirements
Once you have your business requirements document, the real work begins. There are many project management software tools that can help you plan and measure your project. ProjectManager is unique in that it adds real-time tracking to make sure your business requirements are being met.
Monitor Project With Real-Time Dashboards
When you make your plan on our interactive Gantt charts , the last thing is to set the baseline. Now you can track project variance across many of our features. Keeping projects on time and under budget is critical to meeting the business requirements of your stakeholders. To get a high-level view of the project, simply toggle to the dashboard where you can view six project metrics. Get live data on costs to tasks, and workload to health, all in easy-to-read graphs and charts. Unlike other tools that offer dashboards, you don’t have to waste time setting ours up. It’s plug-and-play.
Share Progress Reports With Stakeholders
Being able to view your progress and performance in real time is important for stakeholders and project managers. We have customizable reports that can be generated with a keystroke. As stakeholders don’t need all of the details, filters make it easy to focus on only the data they need to see. Then, easily share the report as a PDF or print it out, whichever delivery method your stakeholders prefer. We have reports on status and portfolio status, time, cost, timesheets and more. It’s a great way for project managers to dig into the data and keep stakeholders updated.
ProjectManager is award-winning project management software that helps you plan, schedule and track your project in real time. Use our tool to make sure you’re meeting all the business requirements in your BRD. Our collaborative platform makes it easy to connect with teams to help them work more productively and stakeholders to keep them up-to-date. Get started with ProjectManager today for free.
- How to Write a Business Case (Template Included)
- Project Requirements Management: A Quick Guide
- How to Write Effective Project Objectives Every Time
- Small Business Plan Template
Deliver your projects on time and under budget
Start planning your projects.
- You are here:
- Agile Business Consortium
- DSDM Project Framework
Chapter 15: Requirements and user stories
Previous chapter: 14 People, Teams and Interactions
15 Requirements and user stories
The importance of a well understood, prioritised and agreed set of requirements is self-evident. However, the attempt to define a full and detailed set of requirements too early in a project often proves to be counterproductive, restrictive and wasteful. It is not possible to define all of the detailed requirements at the outset of a long project. The business environment changes as time progresses; new requirements and opportunities present themselves. As the project progresses, the team understand more about the business need. Defining detailed requirements too early means either needing to change the specification later, which wastes the original work, or delivering to the originally-specified requirements and subsequently failing to adequately satisfy the business need. DSDM acknowledges this dilemma and proposes a better way of working. DSDM advises the capture of requirements at a high level, early in the project. Further detail is gradually elicited as the project progresses, deliberately leaving the finer details as late as practicable, i.e. until the Evolutionary Development and the Timeboxes.
15.2 What is a Requirement?
At its simplest, a requirement is a service, function or feature that a user needs. Requirements can be functions, constraints, business rules or other elements that must be present to meet the need of the intended users.
If the product to be delivered is a custom-built car, the requirements defining this would be more feature-based: √ A means of propulsion √ A maintainable steering capability √ A comfortable place to sit However, it should be noted that the following are not requirements, but solutions: X An engine X A steering wheel X Bucket seats DSDM projects aim to state requirements in a manner which avoids tying them to a particular solution for as long as possible. This is because more flexibility can be retained in how a solution is eventually provided if requirements are expressed as what needs to be achieved, rather than how they will be met from a technical point of view, e.g. “a means of propulsion”, rather than “an engine”. A solution expressed too early may become a constraint on what can be achieved within time and budget.
15.2.1 Categories of requirement
The success of any solution is the product of two aspects:
- what it does (functionality, features)
- how well it performs against defined parameters (non-functional attributes, acceptance criteria, service levels)
220.127.116.11 Functional Requirements (FRs)
Functional requirements express function or feature and define what is required, e.g.
- Visit customer site
- Obtain conference venue
The requirements do not state how a solution will be physically achieved.
- Drive to customer site is one possible solution. However, fly to customer site or travel by train to customer site are potential alternative solutions which may be worth consideration
- Build conference centre is one possible solution. Hire a hotel room is an alternative solution Stating requirements early in the project as what rather than how allows room for flexibility and innovation later.
18.104.22.168 Non-functional Requirements (NFRs)
Non-functional Requirements define how well, or to what level a solution needs to behave. They describe solution attributes such as security, reliability, maintainability, availability (and many other “...ilities”), performance and response time, e.g.
- responding within 2 seconds
- being available 24 hours per day, every day
These NFRs may be:
- All customer facing functionality must carry the company logo
- All customer-facing functionality must respond within 2 seconds to requests
- Hire conference venue might have NFRs of accessibility, security, and availability
15.3 User Stories
15.3.1 What is a User Story?
A User Story is a requirement expressed from the perspective of an end-user goal. User Stories may also be referred to as Epics, Themes or features but all follow the same format.
A User Story is really just a well-expressed requirement. The User Story format has become the most popular way of expressing requirements in Agile for a number of reasons:
- It focuses on the viewpoint of a role who will use or be impacted by the solution
- It defines the requirement in language that has meaning for that role
- It helps to clarify the true reason for the requirement
- It helps to define high level requirements without necessarily going into low level detail too early
User goals are identified and the business value of each requirement is immediately considered within the user story. User Stories are often deemed to comprise three elements - the 3C’s
- C onversation
- C onfirmation
15.3.2 User Story format
The format of the User Story is as follows: As a < role> I need So that These two examples demonstrate User Stories at different levels, but using the same format:
At a project level As a Marketing Director, I need to improve customer service So that we retain our customers.
At a detailed level As an Investor, I need to see a summary of my investment accounts, So that I can decide where to focus my attention. User Stories provide another powerful message. Choosing User Stories to define requirements demonstrates an intention to work collaboratively with the users to discover what they really need. The User Story is brief and intended to be a placeholder for a more detailed discussion later – the Conversation. Much of the detail of User Stories emerges during Timeboxes as part of evolutionary development. High-level User Stories (Epics) are broken down by the Solution Development Team into more detailed User Stories just before development commences on that group of stories. Even then, the User Stories are not intended to be full specifications of the requirements. Fine detail may not need to be written down at all, but may simply be incorporated directly into the solution as part of the work within a Timebox. The user story format helps to ensure that each requirement is captured in a feature-oriented, value oriented way, rather than a solution oriented way. In DSDM projects, User Stories are recorded in the Prioritised Requirements List (PRL). This is the equivalent of a Product Backlog in other Agile approaches.
15.3.3 User Story – the Card
From the PRL, User Stories are often printed onto physical cards, for planning purposes and to help the Solution Development Team monitor progress. The Front of the Card
On the front of the card, the following information is typically displayed:
- A unique “Story Identifier”, usually a number or reference
- A clear, explicit, short name or title
- who is the primary stakeholder (the role that derives business benefit from the story)
- what effect the stakeholder wants the story to have
- what business value the stakeholder will derive from this effect.
The Back of the Card
On the back, the Confirmation area contains:
- Acceptance criteria (the test criteria)
These acceptance criteria define, at a high level, the test criteria which will confirm that this user story is working as required. These are not intended to be the full test scripts, but will be used to expand into the appropriate test scenarios and test scripts during Timeboxes, as necessary. For User Stories at the highest level (sometimes called a project Epic), the acceptance criteria may be used to define the aims of the project using criteria that may be measured after the project has completed (as part of the Benefits Assessment). Project acceptance criteria example:
- Is customer retention improved by 20% within two years?
- Is product range increased by 10% within 5 years?
- Has speed of dispatch improved to within 24 hours of time of order for 99% of in-stock items within 6 months?
User Story Example: Story Identifier: STK001 Story Name: Customer Order Description: As a Customer, I need to place an order so that I can have food delivered to my house. Confirmation: Acceptance Criteria examples: Functional: - Can I save my order and come back to it later? - Can I change my order before I pay for it? - Can I see a running total of the cost of what I have chosen so far?
Non-functional: availability: - Can I place an order at any time (24 hours per day or 24/7/365)? - Can I view the order at any time (24 hours per day or 24/7/365) up to and including delivery? Non-functional: security: - Are unauthorised persons and other customers prevented from viewing my order?
15.3.4 Well constructed User Stories
Bill Wake’s INVEST model provides guidance on creating effective User Stories:
A well-written user story is clear, concise and complete. Some simple checks are:
- It does not combine with, overlap nor conflict with other User Stories
- It conforms to organisational and project standards and policies where applicable
- It is traceable back to the business needs expressed in the business case and project objectives
- Where several User Stories relate to the same feature, but for different users, they are cross-referenced to each other
15.4 Requirements Through the DSDM Lifecycle
- A clear project objective
- A statement of the business vision
- A Business Case, agreed with key stakeholders
These form the anchor for the deliberate evolution of the more detailed requirements, iteratively and incrementally, as the project progresses. As the hierarchy of requirements emerges in expanding detail, as the project unfolds, each requirement/User Story can always be traced back to this original vision, as it evolves to meet the real and current business needs.
15.4.1 Requirements activity during Feasibility
All projects begin with an idea and an expectation of benefits t o give a return on investment. The Business Analyst ensures that the Terms of Reference (which is sometimes vague or unclear) is expanded to provide a clear project objective, a business vision and an outline Business Case . The project vision is clarified and key project objectives are defined. The highest level Epic User Story is the objective of the project. The User Story format can be effectively used to clarify:
- Who needs this? (Do we have the right Business Sponsor?)
- Why do they need it? (What is the key business value expected or needed?)
- What are their expectations? (What are the high-level acceptance criteria?)
The User Story format also helps to identify the key stakeholders with whom to gain agreement for the requirements. In Feasibility, the User Stories (sometimes called Epics or Themes) should constitute a small number of clear statements that are just sufficient to scope the project, to identify whether it is worth proceeding further and to establish likely costs and benefits achievable. DSDM recommends typically less than 10 requirements/User Stories at this point. Non-functional requirements (see above) may also emerge at this point, but these are expected to become clearer and more detailed throughout the project. Some of the more critical ones may be evident from the outset, when the project objective is established, and these need to be captured because they may constrain some of the choices for the project. Even at this high level, User Stories help to focus on the value of what is required.
is a far more effective way of defining what the business needs, than the vague but technically constraining statement:
The user story format helps to bring out the real objectives of a major change.
15.4.2 Requirements activity during Foundations
During Foundations, more understanding of the requirements is needed, sufficient to clarify the scope of the project, prioritise, estimate and formulate a realistic Delivery Plan.
During Foundations, the high-level Epic or Theme stories established in Feasibility are now broken out into simple User Stories (functional and non-functional). User Stories defined by the end of Foundations in a DSDM project must be specific enough to estimate and small enough to fit into a Timebox (typically 2 – 4 weeks work). This is not the lowest level of breakdown that the project will achieve, but by the end of Foundations User Stories need to be just sufficient to allow for estimates of work to be done and to plan a schedule of Timeboxes for the first Project Increment. At Foundations, User Stories are assembled into a Prioritised Requirements List (PRL). The focus is on describing the business need embodied in each User Story, in a way which does not constrain unnecessarily how the requirement will be achieved. Key non-functional requirements should also be considered and documented during Foundations. It may be difficult or impossible to accommodate such requirements if they are discovered too late in the project. The PRL is baselined at Foundations, to give a clear checkpoint for the set of requirements which was used for planning. In this way, new requirements which emerge during development are clearly identified, and their impact can be assessed.
15.4.3 Requirements activity during Evolutionary Development
At the outset of each Timebox, the User Stories allocated to that Timebox will be further investigated. The User Stories from the PRL are broken down into more detailed User Stories which are small and clear enough for the team to work from. The detail is only elaborated one Timebox at a time, and thus the complexity of the requirements is managed. Also, the fine detail is only elicited immediately before that element of the solution is created. This avoids time being wasted on developing detail on all areas up front. During Timeboxes, the detailed requirements/User Stories emerge iteratively. The Business Analyst captures the appropriate level of emerging detail within the PRL, where this is not adequately captured within test criteria, prototypes and the Evolving Solution itself. The Business Analyst also works collaboratively with both Solution Development Team and project level roles to help retain the project’s focus on value and priorities. New requirements may emerge which were not identified during Foundations. The Business Analyst facilitates the consideration and impact analysis of these and records their inclusion or otherwise in the project, based on discussions with the Business Ambassador, the rest of the Solution Development Team and/or Business Visionary. The Business Analyst also records details of, and reasons for, any lower priority requirements being de-scoped by team agreement during Evolutionary Development.
Requirements evolve and emerge in a DSDM project. Analysis of the detailed requirements is deliberately left as late as is sensible, to avoid unnecessary rework and to manage complexity. Because of this, it is important to obtain agreement to a high-level baselined set of prioritised requirements in the PRL in the early phases of a DSDM project. This gives scope, direction and an appropriate degree of control for the project to evolve the detail whilst allowing change to be embraced and controlled.
Next chapter: 16 Project Planning and Control
Agile Business Awards 2023 - Virtual Conference
Wednesday 22nd March 13:00-18:00 UTC | Thursday 23rd March 08:00-13:30 UTC
Book your free ticket
Agile requirements management: a new take on a classic
Some say the classic way of managing requirements is dead, but are agile requirements for everyone? How tough are they to implement? Let's find out.
Gathering and managing requirements can seem like a rather stiff process at a first glance. There’s a certain order and way of doing things, with a wider structure that means to help us organize all that information. But is the old way of managing requirements still the best? As it turns out, the answer to that question may depend.
Many teams out there swear that the old way of dealing with requirements is a thing of the past. Agile requirements management has been growing in popularity over the past few years, with design teams enjoying the added freedom and fresh take on requirements.
The agile way of doing things is all about breaking down the long processes, boosting communication and gaining freedom in the project. It means to help us stay flexible, allowing for a quick change in direction if need be. But what does all that mean when it comes to requirements? How does one write down all the requirements for an agile management? Let’s dive deeper.
What is agile requirements management?
Communication and its role in agile requirements, the requirements backlog: the agile matrix, agile requirements management: best practices, agile requirements management tools.
The agile philosophy started to make waves in the software development industry all the way back in the late 1990’s, as a way of helping teams speed up projects. It represented an innovative approach to help overwhelmed design teams deal with the variables within a project in a more efficient way. Fast forward a couple of decades, and the agile way is a massive hit in the UX sector.
For more information: Check out more details on how Agile came to be over at the Atlantic, in their article Agile Software development: a History .
When we first try to apply the agile philosophy to requirements management, it can seem like the two just aren’t compatible. After all, requirements are crucial and they come with a lot of smaller tasks which can pile up very fast. The illusion, however, is broken when we take a closer look at how agile requirements actually work.
Firstly, agile requirements aren’t entirely free of structure. There is still a certain order and way of doing things, but they are much more relaxed and adaptable than the classic take on requirements.
For example, with the classic way of gathering and managing requirements, the client works closely with the team on the first few steps of the project. Mostly, this is to ensure that the team understands the client’s business and business requirements for the project. Ultimately, the design team sticks to the client like glue at first but only until that first stage of the project is done. Once the requirements are gathered and understood, many clients simply wait for a more refined presentation of the finished design further down the line.
In agile requirements management, that doesn’t happen. Yes, the client’s cooperation is key at the beginning when we need to understand their business and the market. Yes, understanding and gathering the initial requirements works pretty much like the classic way. However, once that stage is done, the client can’t simply step back and wait for the team at the finish line.
In the agile way, everything is organized in short sprints – and at the end of each sprint, the client participates in validating the design and seeing the progress made. In that sense, there is still a defined structure to the workflow – but that structure itself allows flexibility and adaptability. From one sprint to the other, a lot of things may change.
Communication with the client
Like we mentioned before, the client is much more involved throughout the entire project when we keep the requirements management agile. While the first few steps of gathering requirements remain the same, the entire process is much less structured – making it easier for the team to add requirements as they come up.
The whole point of bringing and keeping the client in the mix while the requirements pave the way for a tangible product is to lessen the possibility of misunderstandings and blind spots.
The fact is that having the client with you every step of the way takes a lot of pressure off the team to get the requirements right from the start. It means that both the team and client have margin to spot mistakes, especially when it comes to those main business requirements that will shape the whole product.
In a similar fashion, the increased involvement of the client helps everyone create a design that represents a perfect product in which all functionalities are up to par. In the end, you have a project that needs much less rework and fully satisfies the client’s needs and expectations.
Communication between departments
The way the agile philosophy works is by putting an emphasis on the teamwork between departments, making a more interactive and efficient project. This is also true for agile requirements, which are to be fully discussed and assessed by everyone at the end of each sprint.
This means that every two weeks (the exact duration of the sprint may vary from company to company), we have a golden opportunity to go through the requirements. That means that at the beginning, we’ll have the core business requirements to which members of your team will add requirements from both a technical and design point of view.
These will often be design and technical requirements that designers and engineers will soon identify, slowly creating a more defined concept for the final product. Just like the more classic approach to managing and gathering requirements, it’s absolutely crucial to get input from all corners of the team.
This will help you have realistic requirements and avoid nasty surprises further down the road. Having the point of view of developers, designers, business analysts and the client makes for a sound final product.
This marks a stark difference between the classic way of managing requirements to agile. In agile requirements management, the backlog isn’t necessarily a traceability matrix. Each little requirement is, in fact, written down as a user story . These are written from the point of view of the user, and indicate a specific functionality of value. Here’s a silly example:
“I want to log in so that I can send emails”
This is probably too simple for a real project, but the ideal here is to keep things simple. You want the user stories to be short and functionality-oriented, so that it guides your actions correctly. Over complicate the story, and you risk losing some of the practicality behind the method. Much like a traceability matrix, a simple look at the backlog would tell you: is the log in ready for use? Has it been properly tested and validated?
Having a simple user story has a certain power. Your backlog ought to be a straightforward list of requirements that can show a snapshot of the project’s progress at any point in time. That the user stories are simple, however, is not to say that they are free of details. With each user story, you want to ensure that you can add links to more documentation.
Context and details
A requirement, all by itself, can be deceivingly simply at first. As we’ve seen from past posts on requirements, a single requirement comes with a lot of information. There are the details on the requirement itself, information on how much testing has been done regarding that requirement and the connection between requirements.
It’s important to keep all this information organized, and the agile requirement management method respects this fact. That’s why it’s key to have a backlog that allows you to add as many links to further reading as you may want. That way, you can give your team a clear picture with all the context they need.
The only thing to bear in mind here, is that you want all this information to be accessible but not immediately in view with the requirement. Remember that in this centralized backlog for the project, a lot of different people will read it. Having too much information would make the whole thing confusing and difficult to grasp. And so, much like when we design a videogame in a complex universe of our own creation – progressive disclosure is the best approach here. Let your people dig as deep as they want or need to, on their own.
Building up the product: incremental details
An agile workflow is all about flexibility and prioritizing your resources. In the case of taking requirements and implementing them on tangible wireframes and prototypes, you want to lay the groundwork for the structure of the product and build up as you validate the progress.
That means that when you prioritize your requirements, you want to first implement and validate the bare bones of the design. Things like basic navigation and architecture of main features need to be fully validated before you start to go into functionalities that aren’t particularly central to the design.
Slowly, you’ll add layers of details as your team makes its way through the backlog of tasks, perfecting the design with the green light from the client at every turn. This means that contrary to the first impression, your team is likely to create a series of wireframes and prototypes as opposed to a single prototype that evolves into the final design.
Backlog grooming is a must
In an agile workflow, your backlog is key. In an agile requirements management workflow, your backlog is the equivalent of your requirements document. You want it to be well-kept, organized and carefully planned.
As mentioned before, your requirements ought to be listed out as user cases, from the point of view of the user – in regards to a functionality of value to them. These should always be specific, straightforward and to the point. It’s important that they’re written in a way that is free of jargon, making it as easy to understand for a technical engineer as to a business analyst.
You want to prioritize the requirements that you need over the ones you want. It’s important to cover the basics first, so that you can simply refine the design by adding details as you progress along. And so, you want to make sure that your backlog is carefully prioritized so your team can get the base of the prototype ready before jumping into any detail.
It’s crucial that your backlog is up-to-date. Remember that it’s meant to be a snapshot of the product as a whole, as well as how much progress has been done until that moment.
Agile requirements does not mean forgetting about making big plans or foregoing key documentation. With that said, one of the main characteristics of Agile is the notion that documentation needs to add value. Documentation for the sake of documentation is bound to create more work, lead to confusion and take up a lot of precious time. In agile, you don’t want any excess weight keeping your team down.
That’s why there tends to be a focus on implementing requirements – that’s the main goal. To see requirements come into fruition, see them take tangible form. Something we can test and validate. The goal is never to simply write things down.
Wireframes and prototypes are key
Prototyping and wireframing the requirements down is the very pillar of agile requirements management. It’s about taking a concept, a functionality, and making it tangible. Here at Justinmind, we love rapid prototyping in agile workflows.
Creating several different prototypes that can all work to validate requirements has immense value to the team and to the client. Sometimes, seeing it in real life can change the way the client feels about a requirement or just make the design team change direction. You want that impact. It’s powerful to see a requirement become reality, it puts things into perspective.
This is particularly true for the stakeholders that don’t have experience in UX design. For a business analyst, seeing a written requirement alone makes it difficult to imagine the real product. That imaginary jump is tough when it comes to abstract requirements. You don’t want to leave people wondering what the requirement will feel and look like. You want to show them.
That’s why it’s particularly important to invest in a professional prototyping tool when dealing with agile workflows (of any kind!). The methodology of agile is about keeping things moving, about making progress in a steady way without the burden of classic workflow structures. In this dance, a set of quick wireframes of the requirements can have a huge part to play.
You can read more about the intersection between agile and prototyping with out post: Integrating Agile and UX Design with Justinmind . On the other hand, if you’re more interested in the wireframing aspect, be sure to read our guide to The agile management project cycle for wireframing .
1. JIRA by Atlassian
JIRA might be the best known tool for agile workflows. It makes it easy to have custom active boards where tasks can be assigned to individuals and prioritized. It’s user-friendly, easy to use and quite popular among design teams.
Perhaps the best thing about JIRA is its ability to integrate with prototyping tools. It’s just practical to have a requirement as a task in JIRA, and have that specific task linked to a specific component inside a prototype in Justinmind. Combining the power of JIRA to organize sprints and backlogs, with the prototyping power of a tool like Justinmind can give any project a serious boost.
Justinmind is a very well-planned and complete prototyping tool. The user-friendly interface helps design teams all over the world to create rapid prototypes that quickly capture and represent requirements. Among the features you can find that help the most are the collaborative ones that bring stakeholders together.
Easily shared prototypes, quick diagrams and an endless possibility of interactions. Justinmind brings all of it to the table. Besides, you can enjoy integrations with some of the most popular tools in the market such as Photoshop or Illustrator, testing tools such as Loop11 and UserTesting… and agile tools such as JIRA. It’s the whole package!
Asana is another big name in the project management market. It’s used and loved by design teams everywhere, with users praising its interface and robust features. Among its biggest fans are more technical teams, who enjoy the tool’s ability to keep records straight – especially when it comes to prioritizing tasks.
Among some of the best features, is the agenda. It helps to schedule and program future activities, which can definitely help in a less-structured workflow such as the agile method. Users also love the collaborative features, making Asana a powerful project management tool.
While not as famous as some of its peers, Monday shouldn’t be overlooked. Users are happy with the interface and praise the tool’s structure. The tool works very well on large screens and is well adapted to suit mobile screens – making it, perhaps, the most portable tool for agile requirements. Mondays is known to give its users freedom to create custom active sprints that can suit just about any design team out there.
Monday is a project management tool that is widely popular among smaller teams, with new updates constantly improving on the tool’s user experience. Users are happy to say that each new update is properly tested, with no unforeseen issues.
Brought to us by Zoho, Sprints checks all the right boxes when it comes to an agile project management tool. It’s easy to set up, allows for custom sprints and a well-organized backlog. Users love that the tool makes it easy to tag and attribute tasks to team members, and praise how easy the initial setup process is.
It is true, however, that the tool itself imposes limitations as to the hierarchy between requirements – making it a better suited tool for smaller products.
The wrap up on
Managing requirements can be a complex thing, made even more complex by extensive documentation and old-fashions processes that seem to stretch on forever. Agile requirements represent a new take on an old problem, getting rid of needless documentation and giving team members more freedom to implement requirements. It brings clients into the fold, increasing your chances of getting things right.
As a whole, the agile method of managing requirements improves the chances of success for the entire project by placing an emphasis on collaboration and communication. It can be a powerful way of organizing your efforts, especially if you have the right tools at your disposal. Hopefully, after this post, you’ll be ready to create your own backlog of requirements and start those exciting sprint meetings!
PROTOTYPE · COMMUNICATE · VALIDATE
All-in-one prototyping tool for web and mobile apps.
- Prototyping tools
- UI Design tools
- UX Design tools
- Design Systems
- All features
- Mobile app design
- VR & AR design
- All integrations
- Import from Sketch
- Start from Adobe
- Wireframe tool
- Mockup tool
- Login to account
- Download Justinmind
- Help Center
- Design templates
- Customer Stories
- Learn UX design
- Brand Assets
- Download Free
One of the main tenets of agile methodology is to begin software testing as early as possible in the development process. This is different from the traditional waterfall approach where testing is executed only after the coding phase . In the traditional phase-by-phase linear approach, coding takes place after one or more project teams have first analyzed and prioritized business requirements, then translated these requirements into numerous specification and design documents during the design phase of the project. Here, test cases — the set of conditions or variables used to determine whether a system under test satisfies requirements— are created manually from specifications, which are later used to created tests used by the QA team. This approach really only works if you know with certainty what it is you're building, who you're building it for, and how to build it. In an increasingly VUCA (Volatile, Uncertain, Complex, and Ambiguous) world, where the speed of business and pace of change are accelerating all the time, the agile approach to development and testing is a more practical way to deal with this uncertainty since it emphasizes just-in-time requirements rather than upfront preparation.
User stories, which are part of the popular Scrum agile process framework, are one of the most widely used requirements techniques used on Agile projects. Scrum is so widely used that many people confuse it with the umbrella-term Agile. As an Agile process framework, Scrum takes a time-boxed, incremental approach to software development and project management by advocating frequent interaction with the business during what are known as Sprints (which are called iterations in other agile frameworks).
The simplest Scrum project team (as shown in Figure 2) is made up of a customer/ business unit stakeholder (known as a Product Owner), the team facilitator (called a ScrumMaster) and the rest of the agile development team. Team members interact frequently with business users, write software based on requirements that they pull from a product backlog (a prioritized list of work that is maintained by the Product Owner) that they then integrate frequently with software written by other team members.
Overview of the Scrum Agile Process Framework
Writing Test Cases from Acceptance Criteria
Product backlog items (PBIs) on Agile projects represent the work that needs to be done to complete the product/project, which includes software features, bugs, technical work, or knowledge acquisition. Software features are described from the perspective of the customer in the form of user stories, which are high-level descriptions of desired functionality and goals. For every iteration or Sprint, user stories on the Product Backlog are refined and pulled into the Sprint Backlog, where the agile team will agree on the acceptance criteria, proposed solution approach and estimate of effort needed to complete each story. Acceptance criteria determine when a User Story works as planned and when developer can mark the User Story as ‘done.’ Because each Scrum team has its own Definition of Done to assess when a User Story has been completed, it's a good practice for testers to begin writing test cases from acceptance criteria. Many times, while writing test cases, a tester will come across a case that requires changes to be made to acceptance criteria, which can lead to requirement changes and greater quality.
Epics, Features and User Stories
Items on the product backlog such as Epics, Features and User Stories need to be refined or groomed by the Product Owner and other agile team members as they are moved to the Sprint backlog. Epics are high-level features or activities that span Sprints, or even releases. Features are more tangible expressions of functionality, but they're still too general to build. User Stories are functional increments that are specific enough for the team to build.
Figure: Product Backlog from AgileBuddha
For example, the following Epic
— Allow your customers to access and manage their own accounts via the web
can be refined into Features and User Stories that you can test with acceptance tests. (A general recommendation is they should be granular enough to fit in a single iteration).
Features describe what your software does. In this case, the Feature is
— Customer information can be entered and edited in an online shopping-cart application
User Stories are a further refinement that expresses what the user wants to do from his or her perspective. They usually follow a template like this:
As a <type of user>, I want <some desired outcome> so that <some reason>
A User Story for the example above is:
As a customer,
I want to be able to modify my credit card information
so that I can keep it up-to-date.
User Stories Aren't Requirements
It's important to realize that User Stories aren't formal documents in the way traditional requirements are. User stories are more placeholders for conversations among the stakeholders on a project in order to get agreement on acceptance criteria for a particular piece of functionality. One way to encourage this kind of conversation about functionality is via "Three Amigos" meetings, which involve a product owner (or a business analyst), a developer and a QA tester who get together (either face-to-face or on-line) to review the requirements, tests and dependencies of a feature request on the backlog.
This often means that the product owner or an analyst, as a representative of the business, will take the lead and ask a programmer and a tester to look more closely at a feature. In other cases, a programmer or tester may be the person initiating the meeting and setting the agenda. The advantage of Three Amigos meetings is they provide orthogonal views on the feature under discussion: the business representative will explain the business need; the programmer, the implementation details; and the tester offers opinions on what might go wrong. Conversations on Three Amigos meetings don't have to be limited to three people. In some cases, a tester might want advice from a security expert or a programmer may seek recommendations from a database or infrastructure person. The goal of a Three Amigos meeting should be to encourage at least three different viewpoints, as well as some kind of consensus about acceptance criteria. The Amigos may also determine that a feature is not yet ready for further refinement and elect to push its development to another iteration.
What Makes a Good User Story?
User stories should be well-defined before they are moved to the Sprint backlog. One way of doing this is to follow the "3 C's" formula, devised by Ron Jeffries , that captures the components of a User Story:
- Card – stories are traditionally written on notecards, and these cards can be annotated with extra details
- Conversation – details behind the story come out through conversations with the Product Owner
- Confirmation – acceptance tests confirm the story is finished and working as intended
At the same time, it's worth remembering Bill Wake's INVEST mnemonic for agile software projects as a reminder of the characteristics of a high-quality User Story:
The INVEST Mnemonic for Agile Software Projects
As mentioned earlier, Scrum projects employ fixed-length sprints, each of which usually lasts from one to four weeks, after which potentially shippable code should be ready to be demonstrated. The notion of releasing a prototype, or minimum viable product (MVP), is also important in scrum testing for getting early feedback from your customers. Once the MVP is released, you're then able to get feedback by tracking usage patterns, which is a way to test a product hypothesis with minimal resources right away. Every release going forward can then be measured for how well it converts into the user behaviors you want the release to achieve. The concept of a baseline MVP product that contains just enough features to solve a specific business problem also reduces wasted engineering hours and a tendency for feature creep or 'gold plating' on agile software teams.
A baseline MVP also keeps agile teams from creating too many unnecessary user stories (including acceptance criteria and test cases), which can become a big waste of time and resources. As always on agile projects, the primary purpose of writing user stories and creating test artifacts is to realize business goals and deliver value to stakeholders. This means drafting test cases for a line-of-business enterprise application that will be in use for years should have a higher priority than putting the same effort into a mobile gaming app that might not be mission critical. In the last case, you might be able to get away with using a compatibility checklist approach— combined with exploratory testing— and avoid writing any test cases at all.
Another way to simplify writing test cases is to use behavior-driven development (BDD), which is an extension of test-driven development that encourages collaboration between developers, QA testers and non-technical or business participants on a software project. It focuses on creating a shared understanding of what users require through a structured conversation centered on a business common language and examples. Cucumber Open is the most popular framework to implement BDD in any modern development stack. It includes Gherkin Syntax that defines BDD features in a set of special keywords to give structure and meaning to executable specifications, which is a way of writing down requirements. A BDD feature or user story needs to follow the following structure:
- Describe who is the primary stakeholder of the feature
- What effect the stakeholder wants the feature to have
- What business value the stakeholder will derive from this effect
- Acceptance criteria or scenarios
A brief example of a BDD feature in this format looks like this:
Feature: Multiple site support
Only blog owners can post to a blog, except administrators,
who can post to all blogs.
BDD requires a mindset change in how you write requirements, how you write code, how you write test cases, and how you test code. Having developers and testers use a common business language makes it easier to create a test suite of automated tests since you have direct traceability from requirement to code to test case. These tests cases can be created by automated stubs from acceptance criteria or manually by QA testers during exploratory testing.
A test case might be created as an automated script to verify the functionality per the original acceptance criteria . After doing manual exploratory testing, QA testers might suggest other functionality be added to the application as well as updated test cases be incorporated in the automated test suite.
Creating a Real-Time Requirements Traceability Matrix
One of the outputs of the requirement analysis phase of a traditional waterfall project is a requirements traceability matrix. A requirements traceability matrix is a document that maps each requirement to other work products in the development process such as design components, software modules, test cases, and test results. This is usually implemented in a spreadsheet, word processor table, database, or web page that can quickly become outdated as an application is modified, or additional functionality is added.
Behavior Driven Development, together with test management software , simplifies the process of creating real-time documentation from automated specifications, which can help agile teams better detail which requirements were requested, how they have been implemented, and the set of test cases that verify that implementation .
Explore how SmartBear supports strengthening collaboration, agile testing, and integrating BDD directly to your software release management in Jira with Zephyr Squad Cloud (Free 30-day trial)
5 Essential Agile Techniques to Improve Your Requirements Documentation
- One Comment
In this article, you will find agile techniques that play an important role while creating requirements documentation. You will also find solution to handle the inefficiencies in rigid traditional requirements gathering process. Also learn that how to gather requirements in agile!
Why does Agile play a big role in requirements?
Debatably, one of the biggest challenges in software projects is producing effective requirements. When the requirements aren’t done the right way, there is a high chance of having an unstable foundation in the product lifecycle, which often leads to an unsatisfactory end product. In most traditional projects, the requirements team has a mental barrier between them and other teams. This mental barrier isn’t intentionally created, in-fact, it is more of a cultural issue. Agile techniques play a key role in transforming that closed culture.
Software projects fail when the act of creating requirements becomes solely the requirements teams’ burden. Commercial software products or systems typically evolve at an exceedingly fast pace due to highly competitive markets. A side effect of this fast pace is that the requirements documentation often seems out of date and irrelevant if created using traditional methods that simply can’t keep up the pace. One of the worst feelings as a project team member is seeing your requirements struggle to keep up with the pace of the changing environment. It can be pretty demotivating for the entire team. Agile techniques in requirements gathering can not only help overcome these issues but can also help build a higher quality end product.
At the heart of Agile requirements is…
The aforesaid conundrum is a substantial one but before we jump into discussing the solutions, it is important to understand the basics of Agile requirements.
Agile requirements come in many shapes and forms, but the most common form is a User Story. Let’s understand what a User story is all about.
User Stories, or stories as some might call it (or them), represent customer requirements in a simple written narrative rather than a tedious comprehensive document. It drives forward conversations within Agile teams for planning and estimation. They contain a number of criteria that can be used to determine when a User Story is considered to be complete. A good narrative for a User Story would be something that adds value for the customer, partner, consumer, or stakeholder.
Several stories make a Product Backlog and ideally the whole Agile team is responsible for the health of the Product Backlog. However, a Product Owner (PO) is appointed to serve as the single wring-able neck if something goes wrong with the end product. A dangerous yet common misconception in the Agile world is that the PO is the only person responsible for the Product Backlog which I’m afraid is the root cause of many failed products.
5 Agile Techniques to Improve Requirements Documentation:
1. compliment user stories with supporting artifacts.
In cases where a User story does not have enough detail you may attach use cases, traditional requirements or decision tables. In some situations, a client may demand for more documentation, especially while dealing with organizations that get audited for process compliance for e.g. CMMI. This approach may work out well in that scenario.
2. Create requirements that slice the cake
The best way to do this is by writing end to end User Stories which include smaller feature sets, rather than writing stories that are split across technical boundaries. Splitting stories along technical boundaries creates dependent stories which fails the INVEST principle, which is described below. When writing stories, think of slicing a multilayered cake where each layer represents a functional area of the product. For e.g. front end, middleware, backend, database and so on.
3. INVEST in your User Stories
An ideal User Story would have the following characteristics: Independent, Negotiable, Valuable, Estimable, Small and Testable. This is called the INVEST principle. Make stories as independent as possible. Avoid using stories as written contracts, they should be negotiable. Make User Stories valuable to the user and consumers. A story may not be estimable if the implementers lack domain knowledge or technical knowledge. POs and technical leads need to help the implementers gain the domain and technical knowledge by writing effective user stories which follow the INVEST principle that cause conversations focused towards implementing the User Story. Predefined test criteria should be mentioned in the done criteria of an ideal User Story. POs should take testers’ guidance for this and testers should be proactive in guiding the product owners.
4. Groom your User Stories often
Conduct User Story grooming workshops daily or weekly depending on how soon you need results. I remember being a part of these workshops during my career as a software developer and I can’t tell you how valuable it was. It can be implemented by following these steps. First, brainstorm stories on a whiteboard, then organize them into their user themes, prioritize the stories into high, medium and low and lastly improve high priority stories and make them follow INVEST principle.
5. Don’t be afraid to create prototypes
It is better to spend a small amount of time in building prototypes to just test out the waters. This really helps in bringing ideas to reality and encourages healthy discussions. However, make sure the prototype does not turn into a bulky project and build it so that it can be used in some useful way in the actual product.
What if I have a rigid traditional requirements gathering process?
If you write your requirements using the guidelines mentioned above you should definitely see good results even if you are following a fairly traditional requirements gathering process. The key is to introduce these techniques one step at a time and be patient. However, if you feel it’s highly challenging to create change in your organisation, no worries, it is never too late to start casual conversations about Agile techniques.
Let’s assume there is no User Story grooming process occurring in your project. In this scenario you would want to bring in the grooming process gradually. Before you organize a full blown grooming session have an informal conversation with your team about conducting a User Role Modelling session with your Agile team.
If you explain the benefits clearly and implement it in a lightweight manner there is no reason why they would resist. After the initial set of User Roles are identified, your team can start rewriting the existing requirements using INVEST principle for the identified User Roles.
- Ineffective Agile Requirements most often lead to failed products
- The most common form of Agile requirements are User Stories
- Compliment User stories with supporting artifacts, write well rounded User Stories by slicing the cake, INVEST in User Stories, conduct User Story grooming sessions weekly or daily depending on your needs and create prototypes to compliment your requirements
- If these processes are new to your team you can start by talking to your team about the benefits of these processes and then introduce these processes gradually.
It is never too late to implement these Agile Requirements best practices. If you fear that this would slow down your team then implement these processes in smaller chunks until you see actual valued results.
Remember that introducing these changes may seem risky but the biggest risk is not trying at all!
Join 60,000+ Subscribers
For latest blogs, industry updates and exclusive tips.
* Your email is safe with us, we also hate spam
Free Webinars by ReQtest: Watch & learn
Recent blogs, så lyckades bico group i sitt erp-projekt med hjälp av reqtest.
[vc_row type="in_container" full_screen_row_position="middle" scene_position="center" text_color="dark" text_align="left" overlay_strength="0.3" shape_divider_position="bottom" bg_image_animation="none"][vc_column column_padding="no-extra-padding" column_padding_position="all" background_color_opacity="1" background_hover_color_opacity="1" column_link_target="_self" column_shadow="none" column_border_radius="none" width="1/1" tablet_width_inherit="default" tablet_text_alignment="default" phone_text_alignment="default" column_border_width="none" column_border_style="solid" bg_image_animation="none"][vc_column_text]BICO Groups implementation av affärssystemet Microsoft Dynamics 365 var ett komplext projekt med många länder, roller och applikationer. Dessutom hade projektet en aggressiv tidsplan och en strikt budget. Trots flera utmaningar kunde pilotprojektet lanseras efter endast 9 månader, och strax därefter rullas ut i hela koncernen. En av nyckelfaktorerna var att använda ReQtest som stödverktyg vid lanseringen. I...
Customers / 9th November 2022
Reqtest erbjuder integration som tjänst – få ihop Reqtest med ert ärendehanteringssystem
Att implementera och förvalta IT-system är komplext. Det är många delar av verksamheten som är inblandade, externa leverantörer, olika flöden och processer samt flera verktyg. Allt för ofta blir IT-projekt en börda där det handlar om skademinimering, snarare än att få ut högsta möjliga nytta av sina nya system. Vi på ReQtest jobbar med över 300 kunder och 10 000 användare där vi specialiserat oss på att underlätta för beställarorganisationer att hantera och effektivisera hela införandet av stora system, från...
General / 31st May 2022
Nordtech förvärvar ReQtest
Mjukvarugruppen Nordtech Group (”Nordtech”) förvärvar ReQtest AB som är Sveriges ledande SaaS-verktyg för komplexa IT-projekt och förvaltning. Med över 10 000 användare i 20 länder används ReQtest för att managera och kvalitetssäkra större IT-projekt - från inköp till implementation och förvaltning. I och med förvärvet förstärker ReQtest sitt fokus på den svenska marknaden och har nu ännu bättre förutsättningar att stötta sina kunder i deras digitaliseringsresa. Nordtech är grundat av Pål Hodann och Nils Bergman som båda har lång erfarenhet av...
Company / 16th June 2021
Most Common Problems In Projects Using Excel And Mail
Excel has come a long way since its first use within the world, however, there are still some pitfalls in using it. In a day and age where we have almost every bit of information available at our fingertips, why then do we still primarily use redundant systems? The program itself is easily accessible and, as such, many companies continue to use it. Excel is also a cost-effective standard program that most people can understand. Email falls into a similar...
General / 15th March 2021
Why Should You Plan for Project Requirements Even Before You Have Any?
Many people look at requirements management as the key phase for dealing with project requirements. However, it’s important to do sufficient planning before these requirements exist. This is necessary for setting up the stage for a successful project. The success of any project often comes down to planning and requirements management. With proper requirements planning, the outcome and process of the project will run a whole lot smoother. This helps you to better achieve the desired end goal while creating a more...
Requirements / 8th March 2021
Join the discussion.
I see you don’t monetize your website, don’t waste your traffic, you can earn additional bucks every month because you’ve got high quality content. If you want to know how to make extra money, search for: Ercannou’s essential tools best adsense alternative
Leave a comment Cancel Reply
Save my name, email, and website in this browser for the next time I comment.
Support Email: [email protected]
Invoice questions Email: [email protected]
Pricing / demos Email: [email protected]
Postal address ReQtest AB c/o MPC Consulting AB Box 375 111 73 Stockholm Sweden
Visiting address Gävlegatan 16, SE-113 30 Stockholm Sweden
Try ReQtest About Us Clients Contact Blog
Test Management Bug Tracking Agile Board Requirements Management Integrations
© 2023 ReQtest. All Rights Reserved.
- Test Management
- Test Automation Integration
- Screen Capture
- Jira Integration
- ERP Accelerator
- Success Stories
- Test Manager
- Business Analyst
- Product Owner
- Project Manager
- ReQtest Help
Free Requirements Management E-book by ReQtest:
Fill this form to download now.
How to Significantly Improve Requirements Writing and Communication with Agile
How do you write and communicate effective Business requirements from an Agile standpoint?
I recently worked with a client who was interested in leveraging Agile to improve requirements writing and communication in her organization.
In the pre-call meeting for the class, she asked me, “So how do we establish good requirements between Business and IT? And how do we pass them along and not have to hear from the Business again?”
First, the good news is that there are tangible ways to significantly improve requirements writing and communication.
The second part of this question requires a bit of re-framing.
To expect that no communication is required from the business (or vice-versa) is not a realistic outcome. However, with the right structure in place, requirement communication and delivery will become a productive exercise.
So let’s dig in. Here are some ways to significantly improve requirements writing and communication.
1) INVEST in your requirements
Requirements should follow the INVEST principle. That is, they should be Independent , negotiable , provide value , be estimatable , are about the right size so that they can be implemented by the team, and are testable .
2) Use a “card, conversation, confirmation” approach to agile requirements writing and communication
The most Agile requirements are written from the customer standpoint. A great way to apply this concept to requirements is to use the “ card, conversation, confirmation ” format.
- Card: As a <customer> I should be able to <action> so that <benefit>
- Conversation: Review the card with development team and cover questions. Aim to have conversations to flush out assumptions and mark as ready. Move on when the team unanimously gives a thumbs up confidence vote.
- Confirmation: This is the acceptance criteria that must be met in order to sign off on the requirement. A good way to write acceptance criteria is to use a Gherkin format. Use the vantage of a particular customer/user.
- Example: Scenario 1 – Given <a precondition>, when <action>, I should expect <result>
3) Choose the right level of granularity
Requirements should zoom into the right level of abstraction for the audience in mind. Make sure to keep the overarching goals in sight. Requirements should be born from a high level purpose. They should be increasingly broken down into more bite-sized areas for execution.
All of these levels are relevant since they connect strategy to execution. The levels should connect the why to the what to the how .
- Initiatives – Organizational business goals (KPIs, Business requirements) Ie. Improve speed of content entry by 10% (Executive level)
- Features – Highest level of requirements ie. Content Management and Publishing Portal (Executive-Program level)
- Epics – functional requirements – ie. Content Entry (Program and Team Level)
- Stories – (Team Level) More detailed but (INVEST) small, independent, valuable, estimateable, testable – entail a conversation, have clear acceptance criteria. Ie. Publisher uploads new science publication document.
4) Establish up-front working agreements for better communication
Agile talks about the importance of customer collaboration. There are two types of working agreements that help improve communication between business and engineering. These working sessions happen initially up front and are revisited periodically.
Draft a Definition of Ready
The Definition of Ready (DoR) includes all things that should be included in requirements before they can marked READY to be worked on by the development team. Some examples might include:
1) Clear acceptance criteria are in place
2) The requirements include major design assets
3) The requirements reviewed and acknowledged by the team
Draft a Definition of Done
The Definition of Done (DoD) includes all things that must be completed before declaring the requirement as DONE (or “done done”). Some examples might include:
1) The unit tests have been written and pass.
2) Test Coverage is 80% or better
3) The acceptance criteria have been met
4) The requirement has been reviewed and acceptance tested by the business owner
5) Take smaller bites
Often the pain associated with requirements is related to information overload. This is often where you may find requirements churn.
Break down requirements into smaller chunks that can independently provide business value. Leverage the INVEST criteria. Try to spend no more than a focused 1-2 hours per session to groom the top-most valuable items. Then move down the backlog of requirements and repeat.
6) Have the right people in the room
Have you ever played the telephone game and how did that turn out.
Ensure that the right people are in the room from the get-go. The right people are those who can uncover assumptions of the requirement, or those who can help make the right decisions. Wasted time and effort will be saved in the long run.
For a product owner on a team, this meeting might include the engineering team and designers.
Or for Business Owners, this might be representatives of the financial, marketing and operations teams.
Get everyone aligned in the same room from the beginning and you have already stacked the deck in your favor.
You may find that you have trouble identifying the right people. Step through the requirement end-to-end from a customer standpoint. Try to understand the underlying systems that are in place. Some examples of systems include the Marketing system, Fraud system, Customer Records system and Billing system. From there, identify key people who represent those areas and bring them in.
7) Establish a rhythm
Practically speaking, one of the biggest challenges related to requirements and communication is that Business people in particular often have chaotic schedules, and it is all but impossible to get everyone in the same room.
Are you begging, bribing and stealing for peoples’ time? One of the most effective ways to solve for this is to establish a regular product requirement grooming cadence. So if the events are already established, attendance will improve. With a regular schedule, meetings will be shorter. If you’re a facilitator, this reduces the overhead of scheduling multiple ad-hoc meetings.
Depending on the nature of the project, a focused hour a week can work well for 10-20 person product/engineering team.
8) Visualize the work
Leverage a visual centerpiece around the work. It could be an ordered backlog, or a roadmap showing the current and upcoming features.
This will be used as a springboard to help drive collective conversations about the product. Use an easily accessible, up-to-date medium (like a shared wiki). This will go a long way to simplifying communication and alignment.
9) Hold regular product demos to capture and communicate requirement feedback
One of the most powerful ways to bridge communication and foster continuous product improvement to is hold regular product demos.
In terms of format, these demos are often hosted and led by the engineering delivery teams. The demo is delivered to the business stakeholders.
The intention is to focus on sharing the actual working solution. This activity should be informal and not require much up-front preparation. So leave the slides at home. From this, you can expect a lot of valuable collaboration to spring up. Questions and feedback from the Business can be used to shape the product backlog in the future.
What’s great about this exercise is that it’s unifying, motivating and engaging. The teams walk away with a sense of recognition and appreciation and the business has learned something new.
In Summary: Writing and communicating great Agile requirements
With the right structure in place, your organization will significantly improve on requirement writing and communication.
Incorporate INVEST and ‘Card, conversation, confirmation’. Your Business will be on its way to having clearer requirements.
Break down requirements into smaller more actionable units. Rhythmically include the right people.
Visualize your work. This will lead to a more aligned view. It will permit feedback to refine the product over time.
Finally, foster a common understanding of expectations between Business and Engineering. Establish working DoR and DoD agreements.
Now you have the structure to improve requirements writing and communication. It’s important to take action! Make a conscious effort to apply these techniques daily and you will gain improvements!
Thanks to Daniel Bales and Angela Wick for their valuable feedback.
Daniel Bales www.sharpeyeanimation.com
Angela Wick www.ba-squared.com
Definition of Ready – Jeff Sutherland https://www.scruminc.com/definition-of-ready
Definition of Done – Jeff Sutherland https://www.scruminc.com/definition-of-ready
The Three Cs https://www.agilealliance.org/glossary/three-cs
Communicating the “What” instead of the “How” (Delivering intent) “Greatness” by David Marquet https://youtu.be/OqmdLcyES_Q
Communicating Acceptance Criteria using Gherkin https://docs.cucumber.io/gherkin/reference/
How to Invest in Your User Stories – Jeremy Jarrell https://www.pivotaltracker.com/blog/how-to-invest-in-your-user-stories
About the author
Michael Nassif is a Principle at ZenAgile , a training and consulting firm that specializes in developing high performance, empowered organizations. They take a heart-centered approach by providing hands-on training and workshops in the applications of Lean and Agile.
The high performance agile team told through the hero’s journey, the top reasons for adopting agile in 2021, what the warriors taught me about high performance agile teams, how agile software craftsmanship is key to lasting quality, recent comments.
- January 2022
- November 2021
- January 2019
- September 2018
- Agile Adoption
- Agile Productivity
- Business Agility
- Organizational Transformation
- Technical Agility
- Entries feed
- Comments feed
- Agile Coaching Certification (ICP-ACC): Leading Agile Teams
- Agile Coaching Workshop: The Agile Coaching Discipline
- Leading SAFe
- The ZenAgile Scrum Master Accelerator Training
- Agile Training San Francisco, Oakland & Bay Area
- Agile Training: What it is and why you should adopt it
- Course Schedule
- Recommended Agile books and more!
- The Agile Coach: What it is and What it Entails
Copyright 2020 ZenAgile, LLC
Jan 21, 2021
Agile Requirements Gathering: 8 Tips To Do It Better and Build a Product More Efficiently
One of the most essential advantages of the Agile methodology is the ability to adapt to changes when the project has already started. Agile requirements allow for that project flexibility and transparency compared to other traditional sequential approaches.
Detailed requirements usually are not documented all at once at the beginning of an Agile project. Instead, high-level requirements, typically in the form of user stories, form a product backlog for planning and prioritization.
In Agile, requirements are shared among customer and business analyst, product owner, scrum master, designer, development team. Usually, the team is responsible for choosing a technical approach based on high-level requirements and implementing more detailed statements or acceptance criteria in user stories.
Team goals and project specifics
In Agile, the entire team is involved in defining and optimizing acceptance criteria for user stories, implementing them, testing, and delivering results to the customers.
The development team needs to allocate time for acceptance criteria learning and investigation before starting the development process. This should be taken into consideration while estimating the feature. Everyone takes the time to stop at least to read the user story or task to understand it — ask questions, make suggestions, later estimate and explain their point of view in a grooming session. Ideally, 25% of the user story estimation should be dedicated to the requirement analysis.
If your team starts working on a new project then general info needs to be defined in the discovery phase to understand the goals of the project, who the users are, competitors, stakeholders, risks and constraints, and so on. The client typically describes the general vision of the product in the product requirements document defining all of the above-mentioned without specifying the ways to achieving the desired results. Once the client approaches the development team, further investigation may be necessary to make sure that the team and the client are on the same page. The team examines the problem from a different perspective and proposes solutions.
“A story is a work item contained in the team’s backlog” as under Dean Leffingwell’s book . A user story is a simple way to describe software requirements. It is a brief statement that describes something the system needs to do for the user. User stories are often written in a role-based structure in a form of scenarios. They may have the following template:
As a <user role>, I can <activity> so that <business value> .
According to Bill Wake, a good user story needs to be independent, negotiable, valuable, estimable, small, and testable , acronym INVEST.
- Acceptance criteria
Most backlogs in Agile created at the beginning of the project are not in a good shape for the product. The reason for this is usually a lack of acceptance criteria in user stories.
“Acceptance criteria are the conditions of satisfaction being placed on the system” according to the mentioned above Dean Leffingwell’s book . These statements are described from the point of view of the user to determine when the user story is working as expected . “If all of the acceptance criteria for a user story are met, the product owner will accept the story as being completed” as under “ Software Requirements ” by Karl Wiegers and Joy Beatty.
It’s important to understand the client’s quality expectations and start elaborating on the acceptance criteria right from the start, which shows a thorough QA approach towards establishing adequate KPIs in accordance with the needs of the client early on in the project.
Acceptance criteria are flexible enough to change until the team starts working on the user story. Anyone in the team (BA, PO, QA, developer) can create and review the acceptance criteria.
8 ways to improve the Agile requirements gathering process:
- Add as many details to the user story as possible.
To shorten the time for development and testing and save money for the client you should provide as many acceptance criteria to the user story as possible. Ideally, if the user story has a prototype attached, later you will be able to easily add new or edit existing user stories based on the feedback from earlier prototypes .
2. Adopt a use case approach and template .
Write basic example with required fields for creating a user story or a task in a defect management tool like Jira. Thus, a person who writes requirements won’t forget to fill in any single field.
- How to demo the user story
- All needed hardware/software available for testing
- Affected areas to test
- Where/when needed to be delivered
- PO/BA/Designers POC
- Error handling.
3. Conduct repeated grooming sessions and issue triage .
If after a grooming session some statements are still unclear, clarify this with the appropriate person, ask stakeholders their opinion on the approach. If the description isn’t detailed enough for anyone in the meeting, groom one more time until everyone is on the same page and understands feature specifics.
4. Don’t forget about prioritization .
According to the “Agile software requirements” book by Dean Leffingwell : “ The product owner is responsible for determining and prioritizing user requirements and maintaining the product backlog. In support of Agile Manifesto principle #4 — Business people and developers must work together daily throughout the project — the product owner is ideally co-located with the team and participates daily with the team and its activities.” If this isn’t possible because the PO is on the customer side you can tag him/her in comments to the tickets, write e-mails, organize meetings to discuss the issues.
5. Track requirements status and communicate with stakeholders.
If someone from stakeholders or the development team has commented or replied to the question in Jira or another relevant management tool then these clarifications need to be amended or added to acceptance criteria in the user story. The same applies to design-related documents. All mock-ups should be updated in the user story not to confuse developers so that they know exactly how the feature should be designed.
A good practice here would be to invite a designer to the meeting with stakeholders and then link design explorations to the user story. If communication with stakeholders was conducted via mail/Slack/Skype, then all updated and confirmed data need to be copied to the ticket by the person responsible.
6. Use requirements management tools.
Requirements management tools give the team the ability to trace the life of the requirement back and forth, linking requirements to test cases, design specifications, etc.
7. What shouldn’t be done now.
Keep the team focused by pointing out what you’re not doing. According to Atlassian : “ Flag things that are out of scope at the moment, but might be considered at a later time.”
8. Demo the user story to the stakeholders before releasing to production.
Usually, people don’t always know what they need until they see what they get. Often stakeholders change initial requirements after seeing the full picture and may ask for corrections. You can easily add new or edit existing requirements based on the feedback and new priorities from decision-makers.
So summarizing all mentioned above:
One of the key points of the project success is to figure out how to gather requirements in Agile efficiently and in a way that will most benefit the team and the project. The main focus of Agile is the value of the product it brings for the users. A common practice in Agile is to change requirements during the development process. The result is an increment that may be ready right after one iteration. Usually, the development team is presenting a demo to the customer who can see how the product is working and may suggest improvements. This helps to prevent unnecessary delays and increased costs. Thus, the 3rd principle of the Agile manifesto “Customer collaboration over contract negotiation” is resulting in quicker delivery and value for the users.
And finally, product owner, business analyst, and the development team will learn more about the product as the project progresses, particularly once the software is already in use. This means that they will have more experience from previous iterations and can leverage requirements gathering best practices to achieve better results in each consecutive cycle of the project.
More from Agile Insider
Exclusive and practical insights that enable the agile community to succeed.
About Help Terms Privacy
Get the Medium app
Software QA engineer with more than 4 years of experience working with Agile methodology (SAFe, Scrum, Kanban), ISTQB certified tester, Foundation level
Text to speech
How to Write a Business Requirements Document
Ensure that every project is aligned with your business goals.
Behind every project, there is a business need. Yet there is often a mismatch between what was needed and what was produced. Getting the business requirements right is what can decide the ultimate success and failure of a project. 37% of companies cite inaccurate requirements as the primary reason for failed projects .
To get the desired outcome, first, it's important to accurately define it – that's where business requirements documents (BRDs) come in. It's written to describe why a project is needed, whom it will benefit, and when it will take place.
Let's dive deeper into what business requirements are and how effective BRDs are written.
What are business requirements?
What is a business requirements document (brd).
Business requirements document example
Business requirements document template
The benefits of writing a BRD
A business requirement is the rationale behind the initiation of a project. It describes the overall business goal of a project from the company’s point of view.
The project in question may involve a small-scale process optimization or the development of a brand-new product. Depending on its scope, the business requirements could be a simple description of business needs or a highly complex set of business objectives across multiple domains.
In any case, the business requirements need to be clearly defined for the project to be a success.
Types of requirements
Before getting into how business requirements should be written, it's important to understand where they fit in and how they differ from other types of requirements in product management . Although all requirements may share the same high-level goal, these terms should not be used interchangeably.
Business requirements describe the high-level business needs, without going into how the solution should be implemented. These may involve carving a market share, reducing customer churn, or improving the customers' lifetime value.
User requirements cover the different goals your users can achieve using the product and are based on the value it delivers to them. User requirements are commonly documented in the form of user stories , use cases, and scenarios.
Product requirements are derived from your business and user requirements and describe in detail how the system needs to operate to meet these requirements. They are documented in the form of product requirements documents (PRDs) and include:
Functional requirements – how the product solves the user's problem in terms of functionality.
Non-functional requirements – how well the product solves the user's problem in terms of performance, usability, security, etc.
As the project progresses, functional requirements crystallize into features. Every feature should be focused on satisfying the user's needs within the bounds of the business requirements and goals.
To manage business requirements in an effective and organized way, business analysts and project managers write business requirements documents (BRDs).
A business requirements document (BRD) is a document that describes the problems the project is aiming to solve and outlines the outcomes necessary to deliver value. It doesn't need to include the implementation details of the solution.
On a high level, the BRD aims to answer the following questions:
What are the problems that the business wants to solve?
What are the constraints and restrictions?
Why is it worth to invest resources into this project?
Once you create the BRD, all project requirements should be referenced against it. Any requirement which doesn’t relate to the business objectives listed in the BRD should be either discarded or re-evaluated.
No two BRDs look the same – depending on the company, industry, and project scope, it can be either a very long and formal document, or a simple one-pager. With the growing popularity of the Agile approach to documentation , lightweight and compact requirements documents are becoming increasingly common.
Here's an example of a business requirements document created in Nuclino , a unified workspace where teams can bring all their knowledge, docs, and projects together in one place. Create an account and start writing your own BRDs:
Nuclino can serve as a great internal documentation tool , though it's also versatile enough to be used to manage projects , plan sprints , onboard new employees , take meeting minutes , and more. It works like a collective brain, allowing you to collaborate without the chaos of files and folders, context switching, or silos.
While there is no fixed structure that a BRD needs to follow, it generally includes the following sections and topics:
An executive summary
An overview of the business goals of the project
The context or background of the project
The scope of the solution
A list of project stakeholders
A detailed overview of the requirements
The metrics or indicators that will define the fulfillment of the business requirements
Constraints or limitations (time frame, budget, resources, etc.)
Here's one example of a compact business requirements document template:
There are many reasons why writing a business requirements document is worth it:
It helps you connect every project to the broader business goals.
It gives all stakeholders a single source of truth and keeps them aligned.
It serves as a reference point for all communication between the business and development teams.
A business requirements document is one of the first documents created as part of your project plan . As the project progresses, the BRD continues to guide every decision with regard to prioritization, design, and scope, making sure that your project remains aligned with the overall goals of the business.
But at the end of the day, whether you write a formal BRD for every project is up to you and your team. As long as the business requirements are neatly documented somewhere (like your internal wiki ) and all stakeholders remain on the same page, your project should stay on track.
Nuclino : Your team's collective brain
Nuclino brings all your team's knowledge, docs, and projects together in one place. It's a modern, simple, and blazingly fast way to collaborate, without the chaos of files and folders, context switching, or silos.
Create a central knowledge base and give your team a single source of truth.
Collaborate in real time or asynchronously and spend less time in meetings.
Manage and document your projects in one place without losing context.
Organize, sort, and filter all kinds of data with ease.
Integrate the tools you love , like Slack, Google Drive, Figma, Lucidchart, and more.
Ready to get started?
- Why Nuclino?
- Apps & Integrations
Epical epic. Agile epic examples
What is an agile epic, what to use it for and foremost how?
Requirements. Small, large, technical, business, operational, researchable. And above all, plenty of them. During four years of ScrumDesk development, we have more than 800 requirements in our backlog. And these are only requirements that we have decided to implement without any further ideas that would be nice to have. It is, of course, difficult to navigate in such a long list without any additional organization of the backlog structure. And this is where epic comes to help.
Every Scrum or Agile training introduces the term Epic. In training sessions, epics are presented by only using one image and essentially, they are not even explained assuming their simplicity. It is not rocket science. However, the question emerges as soon as a product owner starts preparing a backlog of the product. How to organize epics? What are they supposed to describe? How to organize them?
Epic is a set of requirements that together deliver greater business value and touch the same portion of the product, either functional or logical.
Agile Epic, similar to the requirement itself (often User story), is supposed to deal with a problem of a single or multiple users and at the same time should be usable and valuable.
How to identify epic?
It is no science at all. Start with thinking about a product from a large perspective. Agile epic is a large high-level functionality. Their size is large, usually in hundreds of story points. However, all these chunks of functionalities must be usable end to end. In practice, we have encountered multiple approaches to epic design. Let’s try to see which one is the best for you.
Epics are managed by product management or other strategic roles. For smaller products, Product Owners identify them. Agile epics help structure your work into valuable parts that can be developed faster while delivering value to users.
I. Epic as a part of the product
Epic can represent a large, high-level yet functional unit of the product. For example, in ScrumDesk we have epics BACKLOG, PLAN, WORK, REPORTS. In the app, you can find parts, and modules, which are called the same way as a given epic.
Top epics of the ScrumDesk product
This backlog organization is appropriate when you are creating a product that you are going to be developing in the long run.
Why use this method of epic organization?
- As a product owner, you simply have to be able to orientate yourself in parts of the product and know what you have or have not finished yet.
- At the same time, it is easy to measure progress by parts of the product.
- Product Owner is naturally urged to change the order of features in the epic , which leads to the creation of rapid delivery of a minimum of viable product increments .
The disadvantage of this method is the lacking view of the user journey It is not visible which parts of the backlog cover what parts of the user value flow. E.g. process from registration, and basket to payment. Each part of the process can belong to a different epic.
Epics, in this case, do not end here, they are not concluded because the functional unit is delivered in a long term. In years. In the roadmap, the implementation of level features of individual epics is planned.
II. Epic as a part of the business flow
This approach is based on the fact, that we know the flow of values, meaning a business process that we can divide into individual parts and then make it more detailed and deliver iteratively. High-level functionalities follow the business workflows.
Epics by the business workflow
For example, an e-shop. Agile epics candidates would be:
- Product catalog viewing – for portraying categories of goods and a list of goods in each category, filtering and searching for goods.
- Product selection – a selection of interesting products such as favorites, comparing, pricing, or adding to a cart.
- The Cart of the products – browsing the content of a basket, comparing, and counting the total price.
- Payment – choice of payment options, total order, total price, shipping, the payment itself, and payment confirmation.
- Product delivery – a visual display of the delivery status, email, and SMS notifications.
The product owner is naturally able to focus on the delivery of the whole customer’s experience . The first fully functional version is then created quite quickly and is subsequently improved iteratively. Epic Payment is based on VISA, transfer, and cash. In the first version, only Visa payment will be delivered, transfer and cash in the next one.
The development of epics takes a longer time in this case. It does not usually make sense to close them, as they will be further elaborated in the future by other features. Business easily understands the state of the implemented application (e-shop) which simplifies communication and significantly improves cooperation between IT and business. It is important to use commercial terms rather than technological ones.
III. Project as epic
Do you deliver products to a client in various phases and various projects? In this case, it may be easier to create epics according to projects or the project’s phases.
Epics as project or phase
Such epics are usually considered finished (closed) when the project is delivered. The advantage is obvious. There is an absolutely clear state of implementation of the project. Participants and stakeholders have excellent transparency. At the same time, stakeholders can focus on preparing for the next phase of the project.
On the other hand, it can be quite difficult to keep an overview of functionalities units of the product itself. The state is more perceived by architects rather than the business itself. In real life, we also came across seeing this way to lead to a change in the company’s focus, or even to the degradation of its vision. A company that once wanted to act as a product and solution maker became a company fully listening to clients. Their products became a ‘toy’ in the hands of clients which led to people leaving teams because they have lost the personal connection with the product. They often lose the power to say NO.
It is also practical to use themes for further categorization of requirements . This creates a virtual matrix, in which each requirement belongs to a certain product set and also might belong to a business theme that is communicated to clients. In ScrumDesk we use, for example, themes for identifying clients who had requested larger sets of features, and we, after all, decided to include them in backlogs. As a product owner, I know how to communicate the status of requirements with a client while still keeping my eyes on the implementation of the product itself.
Epics and Themes
Themes in the product world are often determined by top management at strategic meetings and these topics are subsequently implemented in multiple value streams supported by multiple products. An example of such strategic themes can be 3D Maps, AI (Artificial Intelligence) in risky investments, traveling without physical gates and cards.
In addition to business logic, an application has many parts that create a basic core of a product, but a customer rarely notices them.
First of all, you need to think about and register, for example, the design of architecture, suggestion of UX layout of an app, initial frameworks, and technological preparation. In later phases, the functionalities are still touching the entire product at once. E.g. logging, error handling etc. In ScrumDesk we had an epic called #APPLICATION for such requirements.
When we started four years ago, we decided to keep all bugs in epics titled #TECH. Symbol # indicates artificial epic.
Later we changed this strategy and now we are trying to put every requirement, regardless of its type, under the right epic, as the epic either repairs or expands, improves from the technological point of view.
Epic and business value
In Agile, each requirement should deliver additional business value. However, in the case of more complex applications, it is almost impossible to evaluate the value supplied at such a low level. In this case, it is easier to determine the business value at the level of epic . Epic then can analyze, suggest and prepare ahead of implementation itself beforehand.
It is also possible to create a business case and consequently the business value itself. Such an approach is recommended, for example, Scaled Agile Framework, in which the epic adds value to the selected value stream.
Epics in SAFe
How to prepare epics?
Product Owner prepares epics in advance, prior to planning and implementation.
For good preparation he needs support from multiple people:
- an architect for a rough design of the architecture that is needed to implement the epic,
- stakeholders, for whom the functionality will be delivered, for business value determination and business case,
- UX Designer to work out framework principles of interface design and usability of the epic,
- People from service and support for a good design of epic from the operational perspective,
- And whoever else is needed
PREARE EPICS IN SCRUMDESK FOR FREE
Preparation of an epic can, and often has a different process than requirements themselves. In SAFe ‘Portfolio Kanban’ is recommended for the preparation of epics. Therefore, a separate Kanban board with multiple statuses exists on which the momentum of the epic realization is transparently displayed. This creates space for regular meetings of a small team preparing requirements ahead and continuous improvement of epic details.
Portfolio Kanban systems for epics management
The Product Owner basically works in two-time spaces. In the first one, he prepares epics for the future and in the second he contributes to the implementation of already developed epics.
How ScrumDesk helps with epics?
ScrumDesk supports epics from its first version. As we use ScrumDesk for the development of the ScrumDesk, we identified and tried different approaches to backlog organization. In the first version epics were just titles, later we added possibilities to:
- add more details in the description of the epic,
- visualize epics as colored cards in user stories map,
- added an option to track the business value, risk, effort (as an aggregation of child requirements),
- break down epics into features and/or user stories to manage complex backlogs,
- track comments and changes,
- attach files (i.e. business cases),
- possibility to add the timeline for epics and features with the support of agile roadmaps displaying not just plans, but comparing them to reality as well.
- Epic by technology layer. Database, backend, frontend. Functionality is not covered end-to-end, it only supplies parts of it.
- Epic by product version. The product version is a set of properties from different epics. Unlike the epic, the version has a timeline as well.
- Epic by a customer (stakeholder) to which part of the functionality is being delivered. If you need to evidence the customer, evidence it in a separate attribute and organize the epics according to the procedures above.
- When the product assumptions change, the form of epic organization will not readjust. Adapt and select appropriate approaches as needed. Do not be afraid to work with the backlog and change it so you can orient quickly, you can choose other ways of epics organization and especially to have it transparent for the team as well as stakeholders.
Found this interesting? Share, please!
About the author: dusan kocurek.
How To Write a Business Requirements Document (Template Included)
A business requirements document (or BRD), is a document that clearly states everything that a project entails. A BRD can be the key to a successful project and can help you avoid wasting valuable resources.
Are you ready to learn everything you need to know about how to write a business requirements document? This article will explain in detail what information you’ll need to put in your BRD, as well as step-by-step instructions for creating your own. We know it’s helpful to see an example when you’re starting a document from scratch, so we’ve given you a full example, too.
Plus, you can use our pre-built requirements management template to help you write your own BRD. Once this is done, you’ll be able to start your project even faster using our pre-built project scheduling template .
What is a business requirements document (BRD)?
So, what is a business requirements document? It clearly defines everything that a project entails. It considers all facets of the project, including the expected outcomes and the key stakeholders.
This document outlines what’s needed to reach the intended project objectives. When it’s done well, it should be so self-explanatory that it removes any ambiguity associated with the project work. Nobody is left guessing — everything they need is listed in the business requirements document.
In a paper for the Project Management Institute (PMI) , Paul Burek emphasized that business requirements are the “what” — what an organization wants to do upon completing a project. The requirements define the changes that will come as a result of the project work.
While it might sound overly formal, a business requirements document is a critical element to ensure alignment among all parties involved.
What information do you put in a business requirements document?
Now that we have a loose overview of what this document is, let’s dig into the nitty-gritty of what goes into it.
Business requirements documents are similar to other formal documents such as requests for proposals (RFPs) and client contracts. With that in mind, they often include:
- An executive summary : Write this summary after completing the rest of the document. This high-level section should outline the project requirements and should summarize the following contents of the document.
- Project objectives : Describe the project’s goals and objectives and mention what the work will achieve. What are the outcomes? How does the project align with the goals of the business? To simplify this product management roadmap and ensure it’s succinct, use the SMART system for project objectives.
- A needs statement : This is where you make your case as to why the project is needed. Providing rationale and garnering support from stakeholders and employees is a great way to build rapport with your peers before diving into the rest of the project.
- Project scope : Why is scope management important? Successful projects communicate the work scope from the beginning and stay within the defined boundaries unless otherwise instructed. Clear project scope will help you avoid dreaded scope creep . Find a scoping document template that works for you to clearly lay out your project scope.
- Requirements : After requirements gathering with key stakeholders, you’ll need to summarize all of the project’s requirements in this section. Be mindful of high-level requirements like the “what,” as well as technical requirements like the “how.”
- Key stakeholders : Identify the stakeholders involved in the project and lay out their roles and responsibilities. Who will do the work? What are the expectations of each stakeholder? Will the business need to hire any additional resources?
- Schedule, timeline, and milestone deadlines : Detail the project phases in this section, carefully outlining what is required and when. Create timelines and account for dependencies, as well as unforeseen challenges that could arise.
- Cost-benefit analysis : Your cost-benefit analysis is where you’ll capture the associated costs involved in the project along with the expected benefits to help you build a case for the return on investment (ROI) of the project.
How to write a business requirements document
There’s no denying that there’s a lot that goes into this document. But, writing business requirements and adding them to a business requirements document doesn’t have to be an overwhelming challenge. Follow these tips for writing your own.
1. Start by learning from previous successful projects
If starting this document feels daunting, spend some time reviewing successful past projects completed within the organization.
Look at the documentation associated with these projects and use your insights to outline your new business requirements document. Some elements to consider as you review previous documentation include:
- What worked well
- What didn’t work
- Hurdles the project team had to overcome
- Dependencies that might affect your current project
- Elicitation methods used during the requirements-gathering phase
2. Capture your requirements
Here are the meat and potatoes of this process: gathering requirements . This may consist of many different types of requirements ranging from high-level to technical .
Ultimately, your business requirements document won’t be effective without gathering and capturing all stakeholders’ requirements accordingly.
"A Guide to the Business Analysis Body of Knowledge" ( BABOK® Guide ) identifies commonly used requirements elicitation methods, including:
- Brainstorming : Bring your stakeholders together and elicit ideas and themes for the project. This particular method may be beneficial if there are multiple solutions identified.
- Document analysis : Review all existing documentation pertinent to the project, including previous documentation for successful projects.
- Focus groups : Identify stakeholders to gather input from them on a smaller scale. You can dig into the proposed solutions further with pre-determined stakeholders than you would in a brainstorming session.
- Interface analysis : This elicitation method is particularly beneficial for software solutions and involves user interactions with an application.
- Interviews : One-on-one interviews are a popular way to gather input for requirements. Hone in on the stakeholder’s thoughts and perspectives related to the project and potential solutions.
- Observation : This method of elicitation is beneficial when revamping a process or workflow. When observing a worker’s process or workflow, be mindful not to interrupt them. Instead, ask them to review your documentation post-observation.
- Prototyping : Using a prototype is a great way to ensure that the current requirements meet all stakeholders’ needs. Prototypes can illustrate how a solution might work and help determine if requirements should be altered.
- Requirements workshops : Conduct collaborative workshops with your stakeholders to outline requirements together. Workshops generally have more direction than brainstorming sessions with pre-determined asks of each stakeholder specified at the beginning.
- Surveys/questionnaires : Surveys and questionnaires can help if you’re looking to obtain feedback from a larger group of stakeholders. Question design is important, so be sure to determine how best to pose questions to gather the information you need.
Don’t worry — it’s certainly not essential to use all of the techniques mentioned above. Instead, identify which ones will work best for you and your current product specifics. Throughout the project lifecycle, ensure you listen for impacts to the requirements defined at the beginning of the project and address them as needed.
3. Use clear, jargon-free language
Business documents like these can often be long-winded and heavily detailed, making them difficult for your team members to follow and understand. Remember that this document will be viewed by lots of different stakeholders in various roles, and not everyone will understand technical text. There's no need to include heavy jargon in your business requirement document — try and keep your language clear, relatable, and concise.
A good tip is to include a glossary of terms at the end of your document so that any technical terms can easily be found, and misunderstandings can be avoided.
4. Add visual elements to make content more digestible
Visuals and surrounding context can increase your plan’s effectiveness and break up text-heavy chunks of information.
Research indicates that 65% of the population are visual learners, which means incorporating visuals in your document can help you convey your message and plan in a more compelling way.
For example, a business process diagram is a typical visual seen in a business requirements document. Mapping out business processes in their current state versus the proposed future state can help communicate requirements with ease.
5. Ask team members to review your document
Once you’ve finished your business requirements document, ask stakeholders to review it and validate it. This provides the opportunity for you to confirm you’ve captured all of the requirements accordingly and offers a chance for stakeholders to provide feedback and make changes before the project begins.
As an added bonus, completing a review process also contributes to overall alignment, setting your team up for success from the get-go.
Business requirements document example and template
We’ll admit that all of this can feel a little complex and academic, so let’s walk through a basic requirements document example.
Imagine that your organization wants to find a way to better track employee performance and key performance indicators (KPIs).
For the sake of this example, let’s say there’s currently no system that allows employees to track their performance, so one will have to be selected and implemented. Here’s what a very simple document might look like for this type of project (along with some helpful tips):
1. Executive summary
Our organization is seeking a performance management system to track our overall employee performance, boost retention and morale, and increase transparency between managers and employees.
We aim to have this system launched within the second quarter and will evaluate systems, implement the system, and provide adequate training to managers and employees by June 1, 2023.
There are a number of requirements we’re looking to satisfy, including career path mapping, reporting and analytics, and goal management. A number of stakeholders will be involved in the selection and implementation of this system, including a project manager, human resources, department heads, executives, managers, and employees.
This document details the selection of this system, the objectives, needs, scope, requirements, stakeholders, schedule, and cost-benefit analysis.
2. Project objectives
Use the SMART system for your project objectives:
- We will have all 500 employees trained using our new performance management system by June 1, 2023.
3. Needs statement
Back your statement with data and research, if possible, to strengthen your position:
- A performance management system is needed to increase our employee retention rates, maintain consistency across employee development paths, boost our financial position by up-leveling our talent, and motivate and reward employees. Turnover costs our organization on average $35,000, and implementing this system will allow us to save money by retaining our employees.
4. Project scope
Clearly define what work falls within the scope:
- Evaluating and selecting a performance management system Implementing the performance management system
- Providing system training to managers
- Providing system training to employees
Work with key stakeholders to outline all of the requirements:
- Goal management for tracking progress
- Performance evaluation for mid-year and end-of-year performance reviews
- Career path mapping and succession planning
- Performance analytics
- Coaching and mentoring opportunities
6. Key stakeholders
Identify key stakeholders and outline their roles and responsibilities:
- Project manage r : responsible for holding all parties accountable to the project timeline
- Human Resources : will research performance management systems, gather requirements, provide a recommendation to the Executives for signoff, conduct manager and employee training sessions
- Department heads : share desired needs with HR for a comprehensive list of requirements
- Executives : responsible for signing off on the selected performance management system
- Managers : will be trained on the system
- Employees : will be trained on the system
Outline all various phases of the project along with the deadline for each phase:
- Phase I : Complete requirements gathering with all stakeholders by March 31, 2023
- Phase II : Select a performance management system to recommend to Executives by April 7, 2023
- Phase III : Onboard HR team to the new performance management system by April 26, 2023
- Phase IV : Complete training materials for managers and employees by May 3, 2023
- Phase V : Conduct manager training on May 10, 2023
- Phase VI : Conduct employee training on May 17, 2023
Use a tool like Wrike, to help you visualize your project timeline through a Gantt chart view and keep your stakeholders up to date on your progress.
8. Cost-benefit analysis
Complete a cost-benefit analysis:
- Costs of employee turnover per team YoY
- Costs of resources needed by the project team to implement the system
- Benefits of having employees aligned to company objectives
- Benefits of legal protection for terminations
How to plan a business requirements document with Wrike
A collaborative work management platform like Wrike can take plenty of stress and headaches out of the process by streamlining communication, collecting requirements from stakeholders, and providing visibility into the process. Our pre-built templates, like our requirements management template and our project scheduling template , can help bring those results to fruition even more quickly.
Are you ready to manage projects more efficiently, increase productivity, and decrease risks? Click here to start your Wrike free trial and avail of our pre-built templates and valuable product management resources that will supercharge your business.
The complete guide to vendor management.
Vendor management helps you oversee the contractors and service providers working with...
How to Carry Out a Requirements Analysis
Requirements analysis is a key stage in any project. Here’s how the process works, from...
What You Need To Know About Requirements Gathering
What is requirements gathering, and why does it matter in project management? Here’s what...
Leading сompanies сhoose Wrike
Download our mobile app for your android or ios device.
- Project Templates
- Apps & Integrations
- CA Notice at Collection
- Project Management
- Product Development
- Professional Services
- For Project Managers
- For Marketers
- For Productivity
- For Collaboration
- Project Management Guide
- Types of project management software
- Help Center
- Interactive Training
- User Conference
- Wrike Status
- Wrike Support
- Wrike Partner Program
Latest in Wrike Blog
- 3 Ways Wrike Is More Customizable Than The Competition
- How Wrike Uses AI to Transform the Future of PMO
- 4 Things to Consider When Choosing a Tech Business Location
- How to Create an Efficient Workload Management Process
- What Is the Scaled Agile Framework? SAFe Explained
- How to Leverage the 30-60-90 Day Plan for New Hires
- Omnichannel Marketing Ultimate Guide
How Wrike helps you
- Salesforce project management
- Gantt charts
- Collaboration tools for students
- Task management
- Google project management tools
- Professional Services Guide
- Kanban Guide
- Agile Guide
- Remote Work Guide
- Return To Work Guide
- Marketing Guide
- Scrum Guide
- Product Management Guide
- Digital Marketing Guide
- Go-to-Market Guide
- Collaborative Work Management Guide
- Português (BR)
Sorry, this content is unavailable due to your privacy settings. To view this content, click the “Cookie Preferences” button and accept Advertising Cookies there.
How to write a business requirements document in Agile Agile doesn't rely on lengthy documentation or a control board, but it does need business requirements. Here's how to work business requirements into epics and user stories. By Diane Hoffman, Intelopment Group LLC Published: 30 Dec 2020 Customers want what they pay for.
Writing Requirements requires both skills and practice. A better requirements document can save your organization a fortune with clear communication between the developer and product stakeholders. This, in turn, reflects across the organization, including greater transparency, lesser rework, and improves productivity.
Agile manifesto Scrum Summary: A product requirements document (PRD) defines the requirements of a particular product, including the product's purpose, features, functionality, and behavior. It serves as a guide for business and technical teams to help build, launch, or market the product.
A business requirements document (BRD) is a report detailing everything a new project requires for success. There are seven key components of a BRD template, which serve to provide clarity and context for stakeholders. In this piece, learn how a BRD template can increase your chances for project success.
We use these properties to also report and quickly access previous requirements on an index page showing all the requirements: 2. Communicate the overall goals Be short and straight to the point to explain what you are trying to achieve. 3. Background and strategic fit Why are we doing this?
As noted, the best way to begin writing a business requirements document is to meet with your stakeholders and team to get a clear picture of their expectations. But that's only the start. There are many other best practices for writing a BRD. Here are a few. 1. Start With Thorough Requirements Gathering
At its simplest, a requirement is a service, function or feature that a user needs. Requirements can be functions, constraints, business rules or other elements that must be present to meet the need of the intended users. For example: In a training company with its own training centre:
In agile requirements management, the backlog isn't necessarily a traceability matrix. Each little requirement is, in fact, written down as a user story. These are written from the point of view of the user, and indicate a specific functionality of value. Here's a silly example: "I want to log in so that I can send emails"
Here are some of the most common requirements of agile project management: 1. Functional requirements (FRs) An agile functional requirement identifies a function or features the finished product needs to have. Teams use this information to determine what steps they need to take to produce the desired product.
The Business will bring in the high-level stories descriptions to the session — say one liners. And everyone will have a Conversation and write the fine details together.
Overview of the Scrum Agile Process Framework Writing Test Cases from Acceptance Criteria Product backlog items (PBIs) on Agile projects represent the work that needs to be done to complete the product/project, which includes software features, bugs, technical work, or knowledge acquisition.
Pathfinder Software changed its name to Orthogonal in 2016. Read more. The beginning of a project generates a lot of great ideas. But until a structure or cohesion is applied to these ideas, they end up being a loose collection of separate ideas with no direction. Writing agile requirements brings cohesion and direction to the noise.
5 Agile Techniques to Improve Requirements Documentation: 1. Compliment User stories with supporting artifacts. In cases where a User story does not have enough detail you may attach use cases, traditional requirements or decision tables. In some situations, a client may demand for more documentation, especially while dealing with organizations ...
1) INVEST in your requirements Agile requirements use INVEST to improve writing Requirements should follow the INVEST principle. That is, they should be Independent, negotiable, provide value, be estimatable, are about the right size so that they can be implemented by the team, and are testable.
Software QA engineer with more than 4 years of experience working with Agile methodology (SAFe, Scrum, Kanban), ISTQB certified tester, Foundation level Follow More from Medium Thalion in...
To manage business requirements in an effective and organized way, business analysts and project managers write business requirements documents (BRDs). A business requirements document (BRD) is a document that describes the problems the project is aiming to solve and outlines the outcomes necessary to deliver value.
Agile epics candidates would be: Product catalog viewing - for portraying categories of goods and a list of goods in each category, filtering and searching for goods. Product selection - a selection of interesting products such as favorites, comparing, pricing, or adding to a cart.
Business requirements documents are similar to other formal documents such as requests for proposals (RFPs) and client contracts. With that in mind, they often include: An executive summary: Write this summary after completing the rest of the document.
An Agile Approach for Getting from Visions and Requirements to Test Scenarios. In this course, you will learn how the concepts of Agile, Lean, and Continuous Delivery software development philosophies influence the discovery, expression, and analysis of business needs. You will learn how to express those needs in user story format, as features ...
Writing test cases is a crucial part of ensuring the quality and functionality of software products. However, in agile or remote environments, you may face some challenges and limitations that can ...