SCRUMTISCH meets UX Stammtisch: Requirements Management

At the connect.IT Scrumtisch, people interested in Scrum, agile methods/settings and project management meet every four weeks. The circle of participants is made up of committed people from different industries and fields of activity. Discussions usually take place in an open round of topics, where new participants can also get started quickly and ask individual questions to share their experiences.

Requirements Management

Dr. Andreas Birk, founder and Principal Consultant at Software.Process.Management (SWPM), moderated the 26th Scrum Table, where we addressed the question of how to design good requirements management.

Background: The good old requirements specification vs. user stories

In classic project management according to DIN 69901-5, requirements are described using a specification sheet that represents the customer's wishes (the "what and for what?"). This document is supplemented by a functional specification that describes a solution implementation as a technical concept of the contractor (the "How and with what?"). As soon as the client approves the specifications, implementation begins in the traditional way. Once a specification has been defined, it is binding according to this procedure. Subsequent change requests are mapped as deviations from the basic configuration via a change management system.

With the increasing speed at which technologies are developing nowadays, technical product developments are also subject to greater dynamics. No sooner has one standard been established than the next one follows in some sectors. The customer does not accept outdated technology and will buy from the competition if necessary. Nowadays, product developments not only have to be fast; development teams are increasingly having to deal with unknown technologies, the meaning of which cannot even be accurately described by the client due to their novelty. So how do you deal with this? Do you simply write an incomplete requirements and functional specification?

Agile requirements management approaches this problem with user stories. Here, a product is not described in advance by means of a requirements and functional specification. Instead, during the development process, short narratives (stories) are used to specify which specific customer roles (personas) are pursuing which goal with a product (part). User stories are therefore typically written as cards (user cards) in the style "As <role> I want <goal/desire> to <benefit>". Customer requirements can be added or changed on an ongoing basis, and the development team works through these in fixed time periods (time-boxing). If you would like to learn more about this, I recommend the book "Scrum mit User Stories" by Ralf Wirdemann.

A small excerpt from our discussion

Agile requirements & technical attention to detail

The first question was about what agile requirements management can look like in regulated environments for technical systems. For example, if a train is to be built, how do you proceed with a hard specification such as "brakes"? One conceivable solution here is to include braking performance in the acceptance criteria (Definitions of Done) of a user story. With such important product features, it is also obvious that details should be described. However, in agile requirements management, the aim should be to describe the "big picture" in a meaningful way rather than getting lost in small details and thus becoming inflexible. Whether the development process then proceeds in sequential sequences (waterfall) or iterations - the feedback loops to the customer are decisive.

Long live empiricism!

There are standards for the requirements and functional specifications (e.g. from the VDI and the IEEE), but how do you write a proper user story? One participant at the meeting remarked that empiricism is extremely important in agile development: anything that is appropriate is allowed. And you should regularly check your approach and continue to improve it.

Andreas Birk agreed wholeheartedly. He emphasized that user stories are not requirements specifications. They should be seen as the lightest possible representation of requirements information and used in particular as an opportunity for communication and clarification among those involved in the project. The "Role - Feature - Reason" template creates a very good balance between brevity and clarity. However, he also reported on teams that were able to work very well with only keyword-like user stories because they were so well-rehearsed and had a broad common understanding of the system and area of application. Another useful scheme for use cases is "Given - When - Then", which can be used to achieve a very good transition from user stories to acceptance tests, especially with reactive systems.

Aren't we all a bit DAU?

Personas are a central element in requirements engineering in order to anchor user centricity and promote problem understanding. If you find this difficult, you can get started with personas by using the jokingly named "dumbest assumed user" in software development - a completely uninformed user who nevertheless confronts the system with certain needs and requirements. And here, too, empiricism is alive and well - it would be wrong to create personas and take them for granted. Personas are initially just hypotheses that need to be verified in the field.

Once again, many thanks to Dr. Andreas Birk and all the participants in the discussion. Schwarz IT Infrastructure & Operations Services (SITIOS ) also provided us with a room and drinks - thank you very much!

Next Scrumtisch: 29.05.2017 from 18:30 at SolidIT

The event is organized via Xing, please register, places are limited: https://www.xing.com/events/28-connect-it-scrumtisch-1817422