Requirements Engineering for Agile Teams
SOFTWARE DEVELOPMENT
What happens to Requirements Engineering (RE) in the course of an agile transformation? Is the role of the Requirements Engineer still necessary and how does it relate to the role of the Product Owner? Does agile RE mean managing requirements only in the form of User Stories? How do you provide sufficient documentation? How do you find good Acceptance Criteria? And how do artifacts, methods and documents of “classic” RE fit into the picture? With us you will find answers!
As much RE as necessary, as little RE as possible – in each iteration
Our expertise in Requirements Engineering (RE) will help your Product Owner (PO) and your Requirements Engineers create an understanding in your team about the needs and working methods of the future users. It is important to understand and process the “what” and the “why”, the so-called problem area – lightweight and “just in time”. Namely: as much as necessary and as little as possible. From our project experience, we can tell that it doesn’t matter where the applied aids come from – what matters is that they help the PO and the team.
Right from the start, we keep an eye on the – far too often neglected – testability of the recorded stories and requirements. This approach is a unique selling feature of QualityMinds.
If you want to know whether, how much and what kind of RE best supports you in your agile methodology, you’ve come to the right place.
How can RE and agile procedures work together effectively
In an agile team, the goal of Requirements Engineering is to create a common understanding of the future product as well as its users. First of all, the team must understand the product vision. For example, the team can design a Product Poster with the most important functions, users, partner systems, goals and risks or use the Product Canvas method. Finally, they have to understand what do the User Stories of the next iteration actually cover. A single User Story does not describe all the details necessary for development or testing and it must be supplemented with testable acceptance criteria. In order to decide whether to document more details, the team should ask themselves the following two questions for each story:
- does this story absolutely need documentation, for example for regulatory reasons? These documents should become part of the “Definition of Done”. Corresponding tasks should be created during planning;
- are there artifacts – for example a decision table or a process diagram – that would help the team to implement it? If so, these artifacts should be used in Grooming (also: Refinement). An Artifact Poster can help in finding useful artifacts, since it shows possible formats, application scenarios and associated test methods.
If additional artifacts or documents are neither helpful nor necessary, direct communication between the team and the Product Owner is sufficient. This way, only such documentation is created that offers added value; at the same time, everything the team needs is available in the sprint.
Consulting
As consultants, we support you and your project on site in the following roles:
- Product owner
- Requirements Engineer
- Business analyst
We take this role responsibly, integrate ourselves into your team in the best possible way and deliver the needed work “in time & in budget & in quality”.
Coaching
Alternatively, we support your employees, who already exercise one of these roles, and provide
- a coach for Product Owner/Requirements Engineers/Business Analysts
as a sparring partner, ready to share their experience and knowledge. In particular, we can provide effective support for your team on all topics concerning agile values and procedures.
Workshop “User Story Improvement” (1 day)
Do you find it difficult to cut User Stories appropriately? Are your stories already too often located in the solution space? Are you unhappy with your Acceptance Criteria? Are you wondering how stories and formal documentation can work together in a useful way? Sufficient control over the handling of requirements in agile projects does not come solely from User Stories. Bring your stories with you and we will work out solutions for your unique situation together.
Workshop “RE Improvement” (1-2 days)
Do you think that your Requirements Engineering (RE), be it agile or not, can be expanded, but you are unsure how to approach the topic? Together we take a look at your current approach (more precisely: your RE process and your sample requirements) and work with you to identify strengths and potential for improvement, fields of action and pain points. As a result, you will receive specific recommendations and an initial Roadmap. Agile teams find out above all, just how much and which RE is necessary or helpful in their projects.
We look forward to your request!
What distinguishes us mostly – apart from our “quality mindset” – is our project experience and methodical excellence.
Highly satisfied customers are our capital and our goal at the same time. Do you need support in agile RE? Then let’s clarify how can we help you in an initial meeting!
