Requirements engineering (RE) has a long and successful tradition. Different approaches always existed. Still it is optimized for an artifact driven setup: Individuals pass on documents. Agile practices are however geared for an interaction driven setup where individuals form one “super-brain”. The discussion about requirements is part of the agile conversation. And now, the proven approaches from RE suddenly create friction and bad smells. So, should we forget about requirements?
Werner, a requirements engineer, says: “Requirements drive the development of a software product. This also holds in agile development. Aren’t user stories just another way of managing requirements?”
For Werner, getting and writing down requirements is his job and a key step that has to be made prior to developing a software. He says that this is how a team can manage what they need to do and stakeholders know what they get in the end. Seen in that light, user stories are just another form to document requirements. And requirements engineer Werner has to elicit, document, verify and manage them. This is why Werner formally specifies user stories and hands them over to the developers.
Angela, a product owner, replies: “The people I’ve met in the last 10 years evaluated the software against a few down to earth criteria. They basically rated how happy they (or their users) were with the software because life suddenly became so much more fun, productive or fullfilling.”
For Angela, a software product has an impact on people’s lives. A team developing a new software should strive towards a good balance between costs and impact they make instead of implementing requirements. That’s why Angela uses user stories to manage the discussion about how to create this impact. User stories plan the feedback loop between users, stakeholders and the team.
Why talk about requirements at all?
Requirements engineering appeared because software teams tended to neglect a few fundamental questions:
- Why do stakeholder (i.e. users, customers, sponsors) want this software? What do they hope to achieve and in what situations?
- What do we build so the software has the impact the stakeholders long for?
- What constrains us?
- What is really valuable to do and what not?
Werner full-heartedly agrees and also Angela acknowledges the high importance of the questions. Working on these questions offers quite a few benefits:
- Teams discover and resolve misunderstandings, conflicting stakeholder needs, gaps, and slips.
- Teams split up the whole task in digestible chunks.
- Teams collect information to test the software.
- Teams create materials for experts to e.g. check for security, safety or regulatory compliance.
- Teams keep the knowledge about the why and what alive through-out the software’s life.
- Teams create information to offer a fix priced development contract and especially to accept the software in the end.
Again, such a list could come from Werner and Angela. It seem they both agree on the goals and effects of requirements engineering.
A significant difference: where energy is invested
Werner and Angela disagree on how the conversation about requirements should happen, not that it should happen.
For Werner, requirements engineering is a process of its own with roles, workflows, specific inputs and finally, a defined output, the requirements specification. For Werner, RE is done by the specialists and happens between business process analysis and software design. In Werner’s context, work is split by discipline and artefacts are passed from one person to the next down the development pipeline. Werner is in an artefact driven setup.
For Angela, developing a product is a process where a sketchy idea from the stars is turned into a successful product on the road. Talking about requirements is just an integrated part of the conversation where the team strives to balance such things as user needs, functions to build, fancy UI concepts, performance issues, architectural options, how to test, how to split and the business change that goes with it. Angela is in an interaction driven setup.
Achieving impact rather than implementing requirements
When Werner says that he wants to elicit, document, negotiate and manage requirements, Angela protests. She for sure doesn’t want a separate requirements engineering process; she does not want a person collecting requirements and a team implementing these requirements.
She wants an integrated discussion; which problem to solve, what solution to take and how to make it work. Together with the rest of the team she thus jugles
- research to get some basic data;
- experiments with UI mock-ups, market pitches or technical spikes to validate ideas, to narrow down on the right problem and solution and to get stakeholder commitment; and
- fully developing a piece of software for the next release.
Angela has her focus on:
- IMPACT: creating impact with the product and the service.
- SCOPE: getting to the heart of the solution and optimize value and cost.
- DETAILS: making the team work out the full details so everything plays together smoothly.
- FEEDBACK: gathering feedback to identify misunderstandings, changes, conflicts and gaps.
- KNOWLEDGE: manage communication and keep the team’s relevant know how around the product active and up-to-date.
Angela shrugs and concludes: “Creating a requirements documentation? Sometimes it is helpful, sometimes it is not. I do not need a comprehensive requirements specification anymore and when we write something down, it is mostly after the fact, i.e. to keep the drivers of what we built visible. In users stories, we just record what we need in a way so that a few weeks later, we still know what we meant.
A side note about tools
In an artefact driven setup, artefacts are used to transport information from one person to the next. They must have good quality. Otherwise such a setup does not work well. That’s one of the reasons why use cases, documentation structures, document templates, as well as phrasing templates were developed.
In an interaction driven setup, making sure the interactions happen in due time and boosting how groups can work effectively is a key concern. Thusly tools like user story mapping, users stories, example mapping, team walls, etc. have gained popularity.
Sadly enough, we now find teams that meant to transition into the agile world but did stick to their behaviour of passing artefacts from business analyst to requirements engineer to ux designer to developer and to tester. In the same run, they adopted the agile tools and now work with a backlog and backlog items. “Because, that is what you need to do nowadays and that is what agile is all about.”
The tragic consequence: the teams struggle with the new tools and lose time working out how these can replace the “out-dated” artefacts they used to create before. They actually lose twice: They still do not form one team to achieve a common impact and thusly do not profit from the agile promise, and having inadequate tools they even do this less effectively than before.
The smelly bits and pieces
With the ongoing agile transition there are more and more teams adopting practices designed for interaction drive setups while staying, in their hearts, artefact driven. It may thus be of interest to compare a few smells of the two approaches.
It’s probably quite easy to assign the following smells to (a) a well established interaction driven team or to (b) a trapped artefact driven team. Can you do it?
Team discusses in the retro, how to structure backlog items, what to write down and how so developers know what to implement. They also work out a detailed definition of ready, with a special section for stories with security impact, so the readiness of the story can be checked by the requirements engineers prior to the esimation meeting.
In the sprint planning, the team decides who participates in the effort to nail one of the up-coming larger stories in the next sprint and sets up the initial workshop, the technical spike, the UX mocks and the feedback session with business, users and the data protection expert.
The business analysts work overtime getting the new stories to a level so they can be implemented and makeing sure everything is written down so the developers can do it by themselves.
During a story review in the sprint, a domain expert, a developer and a tester identify a case they did not consider yet. After reflecting, they decide that the developer should add a new story so it can be prepared in the next refinement meeting and considered for the next sprint.
The UX tester sends the test report from the user tests three weeks ago to the PL, cc’ed the lead dev, the ux designer, and some domain experts. The report contains 119 weighted fixes the UX tester identified.
At the end of one intensive day of user testing, the observers – i.e. the PO, some of the devs, the UX designer – discuss the insights from the tests and add what needs to be improved into the backlog.
The UX designer spends the weekend creating high-fidelity UI designs so the story is ready for the estimation meeting on Monday. During this meeting, the devs identify a few important questions and the story is handed back to the requirements engineer to clear the questions with business.
An expert from business, the ux designer and two devs sit together and work out the solution for an upcoming story. A quick drawing on the whiteboard shows the technical approach, a sketch on a sheet of paper the UI and an example map the tricky business rules. At the end of the meeting, they quickly update the story, attach the sketches and then schedule the story for the next estimation meeting.
Devs complain about the PO and that she does not do a good job. The backlog is not perfectly groomed, stories lack important information and priorities are unclear.
Conclusion: lead a conversation
Being able to answer the questions requirements engineering is designed for is important in any context. The approaches fitting an artefact driven team and an interaction driven team are however completely different.
- Artefact driven teams: Separated process to elicit, document, verify and manage requirements, performed by separate persons.
- Interaction driven team: part of the overall conversation, especially in regards to impact, scope, working out details, feedback and managing knowledge.
So maybe we should ignore a lot of the stuff about requirements we have been taught in the last years and focus more on those techniques that help the team lead the conversation to create an impact.