INVEST and SMART are not enough to be happy

8 June 2013
| |
Reading time: 3 minutes

If you google for “courses agile testing”, you get over 15 million hits and the results really show a sound offering. In case you google “courses agile requirements engineering”, you only get 2.9 million hits and the quality of results is poor. Obviously, testing in the agile community is the far more interesting topic than requirements engineering.

I ask: Why?!

Maybe the reason is that it is so obvious. When you already write code, then you write test code as well – hopefully. From my point of view, this unbalanced ratio between testing and requirements engineering in agile development is an impediment in the agile community.

Well, there are already courses on how to write good user stories. The acronyms INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) and SMART (Specific, Measurable, Achievable, Relevant, Time-boxed) are often discussed quality criteria.

What is missing from my point of view is the overall picture in requirements engineering.

Requirements Engineering in the agile context - the big picture

RE in the agile context – the big picture

Just talking about what an epic or a user story is, is very restrictive and a loss for any non-trivial and complex project. Only very few guidance can be found on how to cut epics into smaller parts. This is important for scoping and prioritization of requirements. Or let’s think about the development of a system platform, probably including not only software, with a lifecycle of up to ten or twenty years. There will be more than just a set of epics and user stories. There will be for sure additional artifacts like

  • a business process model,
  • UML models like use case models (still very often existing and used – let’s face this fact),
  • a requirements engineering specification holding additional functional, organizational or quality requirements,
  • a data model or a set of data models.

This set of artifacts needs to be developed and updated identically as an architectural documentation. This is where the questions pop up when getting into reality:

  • How to deal with requirements on different abstraction levels? – Especially with customer requests, wishes and all that stuff not found in a backlog.
  • What is the relationship between a backlog and a requirements specification? Is there any or none at all?
  • When do I cut epics into smaller pieces and what changes do I have to reflect on in my requirements specification (if any at all)?
  • What about UML models? Should I still use a use case model?
  • When working with personas and story boards, do I throw them away or if not, where do I store them?
  • What is the difference between a use case and a user story? – Not even thinking that even there discussions such as “business use case” versus “system use case” might pop up.

… and many more questions.

How to cut epics – how to manage scope

At Zühlke, we are discussing these topics as well as this is our daily life. So we discussed, collected answers, reviewed these answers and worked on these topics. We extracted good practices and collected answers about when to apply what depending on the context. Finally, we created a course out of all that stuff – we call it “Requirements Engineering in an agile environment” – and offer our collection of many agile projects and experience to the public and our clients. It might not be the answer to anything like 42, but I guess we get about 39.

How about a try? See http://www.zuehlke.com/D10116

Comments (4)


Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.

Receive regular updates from our blog


Or would you like to discuss a potential project with us? Contact us »