Re: [scrumdevelopment] Use Cases?
I concur mostly with Goerge. I was a RUP Use Case guy before I became a User Story guy.
> Do use cases have a place in scrum?Both Use Cases and User Stories are compatible with Scrum. Scrum does not dictate one or the other, though the Scrum Guide implies that most Scrum teams use US's while some teams that need 'mission/life critical certainty in behavior' use UC's.
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.
I generally advise intermediate to advanced Scrum teams to move to User Stories unless they have that mission/life critical aspect that makes them feel more comfortable with UC's or something else.
> My intuition is that if a userstory is written correctly, that should be enough to drive discussion and collaboration, and enough for the development of test cases. But is there a void
> between user stories and test cases that requires usecases since the user story only focuses on the "what"?
I think what you are missing here is that "test cases", or the User Story equivalent: , *are part of a User Story* and as such, they are a reflection of the decisions made in the discussion and collaboration you speak of. Without Acceptance Tests, IMO, you have a huge void.
Read about Acceptance Tests in Mike Cohn's book on User Stories (_User Stories Applied_). There's a whole chapter on Acceptance Tests and how to turn those into automated tests.
Rough quote from the book:
A user story describes functionality that will be valuable to a stakeholder of a system or software. User stories are composed of three aspects:
A written description of the story used for planning and as a reminder
Conversations about the story that serve to flesh out the details of the story
Acceptance tests that convey and document details and that can be used to determine when a story is complete
(You might also google for ' description of the 3 C's)
- "Oh, I'm sorry, when I said I wanted it to 'take off like a helicopter,' I meant 'take off like a helicopter from a warzone, where we can carry troops and equipment.'
And there's the rub. The devil is in the details, and sometimes those details means we're off the mark (Harrier vs. Osprey) or things take much longer than anticipated (Osprey).
Someone else made a point here recently about how it's extremely important to a) get to the details, by having the CEO appoint a point person and b) make sure you loop in the CEO iteratively and intelligently (respecting his time) so he can head off any incorrect interpretation of his vision.
I'm not against vision, but a vision is not a "software requirement". Further, a vision is not easily testable, nor is a business requirement, because they often lack the key ingredient of system behavior that you can test against.