Before clients and developers begin the task of developing new software together, it is important that both parties have a clear understanding of the end goal. A “requirements workshop” provides the opportunity to define their project's goals, as well as the individual steps necessary for their completion (user stories), to be determined in the form of an overall product vision.
In the words of Ken Schwabers:
The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is. (Schwaber 2004, p. 68)
Most service providers know that they receive requests for quotes based on only a rough outline of the project. Customers and service providers put a project immediately at risk when they start without a face-to-face (or screen-to-screen) meeting in which the goal and the path toward it are not discussed and agreed upon.
Such situations often play out as follows: An offer is misunderstood through the incorrect interpretation of specifications that don't necessarily include all of the client's requirements. Consequently, the project starts off on the wrong foot, leading most likely to disappointment. The only question remaining is, “Which party stands to lose the most?”
Such a poor start to a project can be avoided by hosting a requirements workshop. Even if it becomes apparent that the project’s planned goals can't be achieved through the cooperation of both parties present, the workshop still leaves you with valuable insight and experience that can be drawn upon in the future. Read on to see what goes on in a requirements workshop.
Step 1: Keep your eyes on the prize – the product vision
Above all, it is important to develop a mutual understanding of the project's objective. This is accomplished through the product vision, which acts as a guide, keeping all actions focused on the ultimate goal. In order to create a helpful product vision, you can start by answering the following questions (also see Scrum Alliance – Product Vision):
- Who will buy/use this product? Who is the target audience?
- Which customer needs will this product address?
- Which features of the product are most important and must not be left out?
- Are there competing products and what are features make this product unique?
- When should this product be brought to market and what is the allocated budget?
The product vision should be clear, concise, free of jargon, and simple to understand for everyone involved, from marketing to technical support. The ideal product vision will fit neatly on a normal A3 page and should be placed in a prominent area of the office.
Step 2: See through the eyes of the user - the user's role
During the development of the product vision, you will have defined a target audience. Users can be further categorized based on a detailed analysis of their individual needs. One method of identifying user roles is the development of personas.
As an example, imagine the following user roles in a classic online job portal:
- Employers
- Applicants
- Recruiters
- Platform Operators
- …
By identifying specific user roles, it becomes easier to formulate concrete product features for each group as well as define the feature's overall importance in the product's ecosystem. A feature that addresses the needs of a larger and/or more profitable user role is generally more valuable than a feature that focuses on a smaller or less lucrative role.
Step 3: Features of success – the product backlog
After you have defined the project's goal in the first step and developed user personas in the second step, it's time to determine the features the product should offer in order to meet the needs of your target audience.
Every planned feature will be detailed within a user story. The individual user stories will together form the product backlog. The product backlog created in the requirements workshop will contain user stories that, over the course of the project, will turn out to be irrelevant and therefore discarded. In further meetings, you will discover new user stories that need to be added as the project develops.
Because of the flexible nature of this part of the process, you can’t expect every possible feature to be anticipated in the initial product backlog. It's much more important to define clear user stories that fulfill the goals of the product vision for shipping the first version of the product. As a rule of thumb, this process begins with a classic brainstorming session.
To create a sensible user story, answer these three questions:
- Which user role is this feature designed for?
- What effect does this feature have in the system?
- What value does this feature offer the user?
To use the example from Step 2: As an applicant [1], I want to use keywords to search through job openings [2] so that I can find an interesting job opening [3].
Before implementation, other necessary user story components, such as customer acceptance criteria, must be considered. (We look at customer acceptance testing in software projects in detail in a separate post.)
Step 4: Knowing what's important – prioritizing the backlog
The results of Step 3 will likely be messy, due to the chaotic nature of brainstorming. Therefore, you will need to organize the product backlog in the fourth and last step, as it is essential to begin right away on the most important and valuable user stories.
The question remains: How do we calculate how much a user story is worth? Trying to determine a monetary value is not likely to be constructive, as there are too many unknowns at the beginning of such a project. It is therefore wise to simplify the process by creating and prioritizing categories. One helpful mode of categorization is the MoSCoW Principle (Must, Should, Could, Won't),
Generally speaking, the value that a feature offers the user can be compared with the estimated cost of said feature. Through this comparison, you can determine the overall value of a user story. Experience shows that focusing on user value is the most sensible approach during the first requirements workshop, while the work required can be estimated and evaluated during further prioritization sessions.
In summary
A requirements workshop lays the foundation for a successful product development that leaves all parties involved with a firm understanding of the project's objective and how to reach it. The requirements laid out in the Product Backlog are prioritized, forming a simple, goal-oriented workflow based on the client's wishes. In this way, the most important aspects of the project are realized in the highest quality, before the implementation of less important features and nice-to-haves.
We can help you define requirements!
Do you have questions about Scrum? Are you or your company interested in becoming more Agile? Are you planning a software project and want the support of a proven course of action? At //SEIBERT/MEDIA, the “Agile” in projects is our focus. With more than 20,000 hours of internal and external project experience with Agile development methods, //SEIBERT/MEDIA is one of the largest and most successful advocates of Scrum in Germany, with the Atlassian tools Jira and Confluence. We would love to help you establish agile principles and work methods in your company - contact us for a free consultation. For more information see the section on agile development in our knowledge base.
Lesen Sie diese Seite auf Deutsch
Further Information
Schwaber, Ken: Agile Project Management with Scrum. Microsoft Press. 2004.
99 Reasons for Scrum
Agile organization at //SEIBERT/MEDIA – from brainstorming to realization
The differences between Scrum and Agile
Codeyard: Helping you craft a successful software development process
