Do Use Cases Have a Place In Scrum?
- Share
-
- |
Read later
My Reading List
In Scrum, requirements are commonly expressed as user stories. But is OK to also make use of use cases in Scrum? And, if so, under what circumstances should you do so?
Do use cases have a place in scrum? My intuition is that if a user story is written correctly, that should be enough to drive discussion and collaboration, and enough for the development of test cases.
First, does Scrum require that we use user stories rather than use cases? Not according to Roy Morien:
Scrum does not mandate any particular way of eliciting and recording requirements, beyond the recommendations of face-to-face conversation, regular stand-up meetings (where you can sit down if you really want to, sprint planning sessions, maybe even user story analysis, but collaborative activity and transparency overall. Working with these guidelines, I guess its up to you what you actually do.
Given that, under what circumstances might you want to use user stories? Charles Bradley recommends:
I generally advise new Scrum Teams to use whatever req practice they did before for the first few months of their transition to Scrum. Learning Scrum is hard enough without having to learn a whole new req gathering process.
Charles Bradley also writes, "[...] the Scrum Guide implies that most Scrum teams use [user stories] while some teams that need 'mission/life critical certainty in behavior' use [use cases]." Adam Sroka disagrees with this approach:
The conventional wisdom is that "critical" applications need more documentation. I believe this to be false. What critical applications need is more (and better) verification. The way to do that is through exhaustive automated testing which most "critical" app teams don't do for no reason that I am able to comprehend.
There may be value provided by use case documentation outside of the purely functional realm, however. Charles Bradley writes:
Well, I worked in the aviation domain for a while, and while I don't have the detailed knowledge to back this up(i.e. which regs require this stuff), the impression I got from our doc efforts was that the purpose of the docs was less about process audit, and more about reconstructing the cause and responsible party of an airplane crash(some regulatory, some lawsuit protection). As such, certain required documentation helped(protected the company) in those efforts, and I see where Use Cases might help prove your case(for not being at fault) better than User Stories.
Like all aspects of Agile methods, the value that use cases bring to the organization should be examined closely. What are you really getting from the effort you spend? After all, as Ron Jeffries writes, "I have not met many actual humans who were all that good at use cases." If you accept that you probably aren't good at writing use cases, is there something else you could be doing that would give your organization more value?
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
Agile Modeling
by
Casey Butterworth
For me, in agile projects even more so than non-agile projects, you need to have more techniques at your fingertips... not less!
Use Cases == User Stories ?
by
Chris Matts
User Stories are a scheduling technique. I like Alistair Cockburn's definition "A promise to a conversation". In reality they are a very useful technique for deferring development using minimal effort.
Use Cases are a means of documenting the interaction between a system and its actors (which may be users, other systems, or even time).
Some people think Use Stories are the be all and end all of business analysis. Some people think Use Cases are the be all and end all of business analysis. In that respect they are very similar. If you are only pretending to do analysis, both are very similar.
Ask any practicing business analyst and you will discover that they are both valid tools/techniques in a much richer toolkit. Other complimentary techniques you will discover in the BA toolkit include state transition diagrams, business models, story boards and definitions of business rules..... and many many many more.
A more interesting question is "Does the Use Case cover the Given-When-Then format of BDD?". Use Cases had preconditions well before Dan and I came up with G-W-T. Its a matter of emphasis though as the pre-condition is often neglected.
Use Case is the class, User Stories are the instances
by
Guido Zockoll
The problem ist the granularity. Some use "change zipcode" as use case, some use "order management" as use case. If both use the same business value centric definition regarding starting event und concrete result, then the user story will describe a scenario of a specific use case.
Consider Smart Use Cases
by
Rody Middelkoop
Only write fully dressed use cases for the mission-critical ones and defer writing as long as you can by applying the YAGNI-principle. Every sprint can be easily planned by prioritizing, selecting and estimating the smart use cases.
Some of the advantages are:
‘Regular’ use cases
- Only user goal level use cases
- Use cases ‘as they are intended’
- A single use case describes a single elementary business process
- Differ in granularity too much
- Law of Large Numbers does not apply
- Textual
Smart use cases
- User goal and sub function level use cases
- Good unit of work and estimation
- A single elementary business process is modeled in a single use case diagram
- A single user goal level use case + auxiliary use cases at sub-function level
- Proven candidate as part of your software architecture and usable for codegeneration
- Visual and less textual
Re: Consider Smart Use Cases
by
Dennis Doomen
Re: Use Cases == User Stories ?
by
Roy Phillips
I use User Stories to represent a high-level requirement, whereas Use Cases are one possible artifact created/updated by the process of analyzing requirements (by the whole team of course): one is an input, and the other an output.
Getting stakeholders to focus on what they need this way, and to iterate the conditions of satisfaction for it gives a starting point for elaboration, during which collateral artifacts like Use Cases, BPM diagrams, wirefames, etc., may be produced in the process - if they help the team to understand what they are building.
I have found business/product/stakeholders to be much easier to engage using Stories than UCs - but there is value in UCs as a record of what has been implemented. However, can you be sure the UC was updated? With CoS/UAC/Unit tests you have proof
They have their place
by
Adam Nemeth
- Obvious ones -> noone documents them
- Mostly obvious ones -> user stories are enough
- Thought to be obvious / complex ones.
For the 3rd type, use case analysis is for the rescue.
Somehow most people associate use cases with those idiotic bubbles with line-figures stuff they learn when studying UML, and seemingly noone explains them that they're just the table of contents for some much more broader thing.
Use-case based analysis is one of the most secure ways of understanding your client.
It's a way to avoid misunderstandings.
It's a way to have precise(!) effort-predictions (1-2 days plusminus per sprint for me)
It's a way to make sure everything needed is in place.
It's a way to solve the condradictions existing in the customer's mind about the idea.
Use cases are the sure way to go. In case you have troubles, arguments, misunderstandings, drop this agile stuff, and use them for your - and your team, and your product's - own safety.
Educational Content
Clojure in the Field
Stuart Halloway May 23, 2013
Tuning the Size of Your Thread Pool
Kirk Pepperdine May 23, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think