writing business requirements in agile

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?

Requirements on-a-page

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:

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.

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.

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.

Click here to browse ProjectManager's free templates

Deliver your projects on time and under budget

Start planning your projects.

Chapter 15: Requirements and user stories

Previous chapter: 14 People, Teams and Interactions

15 Requirements and user stories

15.1 introduction.

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:

15.2.1.1 Functional Requirements (FRs)

Functional requirements express function or feature and define what is required, e.g.

The requirements do not state how a solution will be physically achieved.

15.2.1.2 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.

These NFRs may be:

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:

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

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:

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:

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:

15.4 Requirements Through the DSDM Lifecycle

Projects need:

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:

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.

15.5 Conclusion

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.

what is agile requirements management for tech projects

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.

agile requirements management: relationship between client and design team

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.

communication with clients for agile management and gathering

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.

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.

team work and communication between departments

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?

backlog of tasks in angile requirements management

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.

adding details to prototypes with agile requirements

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.

importance of backlog grooming in agile requirements

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.

implement rather document requirements in agile projects

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.

using wireframes and prototypes in agile projects

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.

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.

2. Justinmind

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.

asana as an agile project management tool

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.com as tool for agile requirements

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.

sprints by Zoho as an agile project management tool

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.

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:

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:

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)

Additional Links

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.

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

Contact Information

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

Free Requirements Management E-book by ReQtest:

Fill this form to download now.

[email protected]

1.510.629.9283

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.

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 .

4) Establish up-front working agreements for better communication

Agile definition of ready and definition of done to improve requirement 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

Agile take smaller bites by working incrementally on requirement writing and communication

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

Visualize around the work to improve communication and requirement writing

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!

Contributions

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 Principal Agile Trainer ZenAgile

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.

Agile Resources

https://zenagile.com

Agile Insider

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.

User stories

“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.

For example:

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:

Wrapping Up

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

Olha Kutniv

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, user requirements, product requirements, functional requirements, non-functional requirements

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?

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.

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?

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:

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.

scrumdesk backlog principles fundamentals epic theme user story product owner scrum agile product management

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.

Artificial Epics

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:

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:

Common mistakes

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:

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:

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:

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:

5. Requirements

Work with key stakeholders to outline all of the requirements:

6. Key stakeholders

Identify key stakeholders and outline their roles and responsibilities:

7. Schedule

Outline all various phases of the project along with the deadline for each phase:

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:

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.

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.

For customers

For partners

Wrike Partner Program

Latest in Wrike Blog

How Wrike helps you

Sorry, this content is unavailable due to your privacy settings. To view this content, click the “Cookie Preferences” button and accept Advertising Cookies there.

IMAGES

Agile Release Plan Template Inspirational 40 Simple Business Requirements Document Templates
Word Business Use Case Template
Writing Agile Requirements
Business Requirements Template (Word)
40+ Simple Business Requirements Document Templates ᐅ within Product Requirements Document
Agile Business Requirements Sample

VIDEO

AGILE I BUSINESS ANALYST RESPONSIBILITIES
Closed User Stories
Tips to write effective user Stories
AGILE I BA I Role of a Business Analyst in Agile Environment
agile methodology and requirements
The Business Case for Agile in 2020

COMMENTS

How to write a business requirements document in Agile
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.
The art of writing good requirements
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.
Creating a lean, mean product requirements machine
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.
Business Requirements Document Template: 7 Components [2022 ...
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.
A Guide To Agile Requirements Documentation
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 to Write a Business Requirements Document (BRD)
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
Chapter 15: Requirements and user stories
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:
Agile requirements management: a new take on a classic
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"
Agile Requirements: A Definitive Guide (With Benefits)
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.
5 effective ways to instantly write better agile requirements
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.
How to write agile test case requirements
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.
Writing Agile Requirements
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 Essential Agile Techniques to Improve Requirements ...
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 ...
How to Significantly Improve Requirements Writing and ...
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.
Agile Requirements Gathering: 8 Tips To Do It Better and Build a
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...
How to Write a Business Requirements Document (BRD)
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.
How to write epic and Agile epic examples
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 Document Template & Guide
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.
Agile Business Analysis: Getting / Writing Lean Requirements
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 ...
How to Write Effective Test Cases in Agile or Remote Environments
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 ...