Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Re: Use Cases - a "Bridge" between the "what" and the "how"?

Expand Messages
  • Charles Bradley - Scrum Coach, CSM, PSM I
    Roy, I m sure you saw this coming, but I have to strongly disagree with your definition of User Story. Both Cohn and our fellow lister Ron Jeffries make it
    Message 1 of 73 , Nov 4, 2010

      I'm sure you saw this coming, but I have to strongly disagree with your definition of User Story.

      Both Cohn and our fellow lister Ron Jeffries make it very clear that a User Story is more than a sentence.  Oh, you also mentioned the conversations... so you got 2/3 in my book.  What you and much of the industry fails to grasp is that User Stories require a 3rd component, the "Confirmations" or "Acceptance Tests" - which are descriptions(documented or not) of what will constitute success for the story.  They are also the place the people put most of the system behavior details(such as logic, error conditions, order of flow, etc).

      Cohn in more recent years on his website has also failed to mention acceptance tests, and I called him out on it recently.  (of course he talks a lot about it in his book)  His response was that I was right to bring it up, and he said he would update his website materials on US when he got around to it, but that it may be a while because he's slammed.

      So, with that context, writing one or more UC's for  a US, while not horrible, is also not terribly efficient, either, and in my view is an attempt to replace Acceptance Tests with Use Cases. 

      Most of the value of Use Cases comes from documenting the boundary between User and System(this is both Cockburn's advice and my experience), but as you mention, you can do them at differing levels too if that adds value.  Further, I would argue that the detailing of a UC is almost exactly analogous to the detailing of a US -- it is meant to be a  *result* of a collaboration.

      Detailed Use Cases will take more time and include much more detail than a User Story, as you mention.  To me, this is the major distinction in terms of efficiency.  Sea Level UC's(the ones that document user/system boundary) require the details in a way as to specify the user/system interaction down to a fine detail, including order of operations.  User Story Acceptance Tests take a less specific road by saying "Just tell me *what* needs to happen for success, not *how* the interaction must play out".  The other big difference is that while UC's are supposed to also correspond to TC's to ensure closure(which then may be automated), US Acceptance Tests being converted directly into automated tests is what gives US's a more efficient mechanism.  To me, it's almost as if US skip the UC part and go directly to a detailed Test Case.  Another major distinction is that, in order to be effective, UC's, at the time they are used to spur development, must always document all current behavior, and the new/changed behavior, in order to be useful.  US's take a more streamlined approach and just document the new/changed behavior.

      The overall theme difference I see as someone experienced in both, is that UC's(and their associated Test Case docs) require much more time and much more detail than US's, and UC's specify system behavior in MUCH more detail than US's.  As such, IMO, 99%+ of the time, it's a better choice to use US's, but I leave open the possibility that there are extreme corner cases where spending the added money to get the added level of detail *might be* a wise choice.  As many have said here, though, generally speaking, it's better to spend more time/money writing tests than it is to spend the same time/money going into fine grained details in a Use Case.  I also leave open the possibility that there are projects where the risks involved (wrt specifying expected system behavior) are more important than the money saved by going the less specified route of US's -- and as such, a reason a team might choose UC's over US's.  (I also leave open the possibilty that a team can both do extensive automated testing *and* UC's, but again, that costs a lot of extra time/money.)


      From: Roy Morien <roymorien@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Thu, November 4, 2010 3:48:38 AM
      Subject: RE: [scrumdevelopment] Re: Use Cases - a "Bridge" between the "what" and the "how"?


      I think that there is a fundamental lack of understanding about the difference between Use Cases and User Stories. Perhaps what follows is just my take on it, and may not be totally kosher, however.
      To me, a User Story is "A short, simple sentence, from a User, about a requirement". Note, comes from a User, is short, is simple, is about one requirement. It would usually be couched in the terms and language that the user understands, unless you have managed to educate the user in the formal structure of a user story (which I think is unnecessary anyway). The User Story initiates a conversation between user and developer, which becomes a conversation about design and implementation, gaining more detail and more information from the user, and having feedback and close collaboration between the user and the developer. This conversation carries on throughout the time that the user story is being developed. To assist in information gaining, any number of devices and tactics can be used, such as story boarding, JAD sessions, prototyping, usage scenarios ... and Use Cases.
      Developing a Use Case is very much within the scope of design ... designing the algorithm, the usage paths etc., down to sufficient detail often to extract code logic and structures. Use Cases can, as is the case with many such design aids and artefacts, be stated at various levels of detail.
      I certainly wouldn't see a Use Case as being like a User Story, and being used to initiate the development conversation. In fact, I could even see a set of Use Cases being associated with a User Story. The User Story starts the discussion by stating what is wanted, and the Use Cases extrapolate the what into the How.
      Now, whether or not the development of the Use Cases is considered to be useful, is very much an opinionated matter. Personally, I think sketched Use Cases at a reasonably broad level of detail are useful. Fully documented and detailed Use Cases are not useful, in my view. Or at least, they are too time consuming, and come under the slogan of 'deliver code, not documentation'.
       So, why are the Dev Team writing User Stories? I would think that the only reason for this would be to break down an epic into smaller User Stories, thus helping out the users who don't fully understand about how to write User Stories.
      But, as is so often the case, developers have to perform unnatural acts because of imposed ways of doing things, such as having a BDUF document foisted on them. At least the developers seem to be trying to haul the situation back into an agile style activity.
      Roy Morien

      To: scrumdevelopment@yahoogroups.com
      From: dshelton94501@...
      Date: Thu, 4 Nov 2010 03:48:30 +0000
      Subject: [scrumdevelopment] Re: Use Cases - a "Bridge" between the "what" and the "how"?

      I'm working with a trying-to-be-"scrum" dev team - just started - and found out today they had the Dev team writing the User Stories, and (surprise) they were having problems with their sprints. It occured to me that a fundamental problem with this is that - since they were writing their "user stories" based on BUFD req docs from the Product Management (read: PO), that (apart from the whole concept that Dev shouldn't own the "what")is that they were essentially breaking down to "large" tasks, focused on "how" rather than "what". That raises a some questions I'd love to get feedback on. I haven't seen any good guidelines for breaking down User Stories into "programable tasks". When I've worked with teams that did this, our Sprint Tasks were essentially a combination of "what" and "how" - e.g.: "<how>Write Class X to <what>discombobulate the thingamajig"

      (1) Is it generally accepted that Sprint Tasks will be some combination of the "what" from the User Story (assuming yes, that indeed User Stories have been adopted for requirement in the Scrum) they were broken down from and the "how", with the code itself being the definitive "how"?

      (2) Why not use Use Case (models) to help developers not used to working with User Stories understand the flow of what they are supposed to build ("how") better? (B-T-W: I'd be extremely curious to hear what Scott Ambler's take on this would be - anyone know any group posts he follows?). Or if you XP-adherents out there have an argument against Use Cases - any other types of modelling you might think would help bridge that gap between "what" and "how"? IMHO, that's what modelling is all about - - -and in my experience, most "good" POs can understand and work with Use Case models -

      (3) Is it thought that well written Acceptance Tests - perhaps done by the POs initially - can serve to bridge that understanding of "what" and "how"?

      --- In scrumdevelopment@yahoogroups.com, "JackM" <jack@...> wrote:
      > Absolutely, user cases can play an important role.
      > I find that use cases help mostly to describe the bigger picture which can get lost in user stories. I would use them sparsely in order to get this big picture accross.
      > Remember the important thing is not to spend time documenting unnecessarily. So there needs to be a balance really between documenting these use cases and talking, brainstorming etc using stories and acceptance test criteria to define the requirements.
      > But good use cases really helps to set the stage.
      > Jack Milunsky
      > www.agilebuddy.com
      > blog.agilebuddy.com
      > twitter.com/agilebuddy
      > --- In scrumdevelopment@yahoogroups.com, "sakendrick" <scott.kendrick@> wrote:
      > >
      > > 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. But is there a void between user stories and test cases that requires use cases since the user story only focuses on the "what"?
      > >
      > > Curious what people are practicing... I've read several articles with mixed opinions on this - some state that user story and use cases are just different methods of communicating requirements or expectations (use one or the other), where as other say they are different animals and in some situations you need the detailed use cases.
      > >

    • Charles Bradley - Scrum Coach, CSM, PSM I
      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
      Message 73 of 73 , Nov 9, 2010
        "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.


        From: Ron Jeffries <ronjeffries@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Mon, November 8, 2010 6:46:06 PM
        Subject: Re: [scrumdevelopment] Re: Use Cases?


        Hello, PSM. On Monday, November 8, 2010, at 4:09:51 PM, you wrote:

        > "I want a plane, that also can take off like a helicopter. You guys/gals are
        > smart people, so you can do that, right?"


        Ron Jeffries
        Without practice, no emergence. -- Dougen Zenji

      Your message has been successfully submitted and would be delivered to recipients shortly.