{"id":228,"date":"2010-12-02T11:17:39","date_gmt":"2010-12-02T10:17:39","guid":{"rendered":"http:\/\/leanmagazine.net\/?p=228"},"modified":"2024-03-15T15:18:50","modified_gmt":"2024-03-15T14:18:50","slug":"a-use-case-is-to-a-user-story-as-a-gazelle-to-a-gazebo","status":"publish","type":"post","link":"https:\/\/leanmagazine.net\/req\/a-use-case-is-to-a-user-story-as-a-gazelle-to-a-gazebo\/","title":{"rendered":"\u201cA USE CASE IS TO A USER STORY AS A GAZELLE TO A GAZEBO\u201d"},"content":{"rendered":"

\"\"Requirements Management has for a time been a hot topic within the Agile community, and a religious war has seemed imminent between the followers of user stories on one side and use cases on the other. The rebelyell of the user story-buffs have often been \u201cout with the old and in with the new!\u201d \u2013 and many have seemingly been against use cases merely because they have RUP written all over them. On the other side we have seen use case devotees in white coats mocking user stories lecturing that this unscientific bumblebee cannot fly.<\/strong><\/p>\n

Lean Magazine has talked to one of the greatest experts on the matter, Alistair Cockburn, who has not only been a leading profile in Requirements Management for twenty years, but also has a moderate view on the pros and cons of the two concepts.<\/strong><\/p>\n

Alistair Cockburn\u2019s engagement in Requirements Management started in 1991. He was working for IBM Research in Zurich and needed a way to return to the United States. IBM had just started the IBM Consulting Group, and was constructing a methodology for its consultants to use.
\n\u201cAt that time it was mostly based on Information Engineering, i.e. dataflow modeling and databases,\u201d Cockburn recalls. \u201cBut they needed a track for the emerging Smalltalk and C++ projects\u00a0\u2013 that was my assignment.\u201d<\/p>\n

Noun- or verb-based? <\/strong><\/h3>\n

During those days, the object-oriented modeling, design and programming parts were relatively obvious: There was the Booch\/Rumbaugh school of OO modeling, there was the Cunningham\/ Beck\/Wirfs-Brock school of responsibility-driven design, and there were the programming languages Smalltalk and C++.<\/p>\n

\u201cHowever, those left a large gap in the area of requirements. It was not clear to me that requirements should be object-oriented just to follow the design being object-oriented.\u201d Cockburn discovered Ivar Jacobson\u2019s 1987 report on use cases from the OOPSLA conference, and found they had a perfect fit for the information he was missing in the methodology:
\n\u201cWhen I say perfect fit, what I mean is that object-oriented models are all noun based \u2013 they name the nouns in the domain. Use cases are all verb based \u2013 they name the actions being taken by the people and the nouns in the domain. Having all verbs or all nouns leaves a big gap in the model. Having use cases tells us what to accomplish; having objects tells us what will accomplish that. In some sense, it is like having the warp and weft in weaving \u2013 some threads run vertically, some run horizontally. You need both. Paying attention to that nounverb issue has been a big help to me in navigating the choppy methodology waters. I still use it to this day.\u201d<\/p>\n

Getting the big picture <\/strong><\/h3>\n

Today, Cockburn always starts with use cases in order to get the big picture. These use cases can be written quite briefly, perhaps two paragraphs to a half-a-page or at worst a page, so this is generally useful inquiry and not onerous writing.<\/p>\n

\u201cWithout the big picture I (and others) have no idea what we\u2019re trying to build, its shape, size or complexity. I use the discipline surrounding use-case writing to shine a light into dark and hidden corners, and expose potential trouble spots. This shape then guides what happens next.\u201d
\nOnce the \u201ccoarse-grained use cases\u201d are in place, Cockburn is \u201cfairly indifferent\u201d as to whether use cases or user stories are used after that.
\n\u201cIt\u2019s very much a question of how much the people involved can keep in their heads and how good their conversations are. I do like to use the discipline surrounding use cases to check for extension conditions and extension handling, and would apply some version of this discipline in all cases.\u201d
\nHowever, use cases have one major limitation with short iterations: It is impractical to implement an entire use case in a single iteration.
\n\u201cPersonally, this doesn\u2019t bother me, because I\u2019m happy to put the use case on the wall and simply color the sentence in the use case being implemented in this iteration. Coloring them like this allows me to implement individual sentences or even phrases from the use case set in any order I like, and to always see what\u2019s done, what\u2019s stacked to be done, what\u2019s in progress, at any given time. In this sense I don\u2019t need user stories at all.\u201d
\nIn Cockburn\u2019s experience few other people are willing to do the above coloring. Instead, they prefer to see separate work items listed on separate cards or as separate line items. For these people, cutting the use cases into user stories is pretty much a necessity.<\/p>\n

Use cases have limitations <\/strong><\/h3>\n

According to Cockburn, there are two occasions when use cases really don\u2019t serve a useful purpose. The first is for CAD\/CAM tool-type systems. In these systems, there is no plot line for the story embedded in the use case. There are only many different tools the user can bring to bear.
\n\u201cIn such cases, I would quickly shift from high-level, coarse-grained use cases to features lists (and I wouldn\u2019t even call them user stories, just \u2018features\u2019).”
\n\u201dThe second occasion when use cases don\u2019t serve a real purpose is in bug lists and feature enhancement lists. Related, once the system is fairly far along in implementation, the ongoing requests from users look more and more like feature enhancement lists.\u201d
\n\u201dAgain, I wouldn\u2019t call these user stories except in deference to the implementation group if they are in the habit of saying \u2018user story\u2019 instead of \u2018feature\u2019 or \u2018product backlog item.\u2019 In the case of long bug or feature lists, I would just work from the list.\u201d
\nIn contrast to this, Craig Larman \u2013 chief scientist at Valtech \u2013 claims that he likes user stories because they scale up to really, really large requests (like \u201cimplement the entire system\u201d). In a way, both use cases and user stories could be regarded as fractal. Larman makes use of this fractal nature of user stories to break really big projects into manageable pieces, each time using the \u201cmarker\u201d characteristic of user stories to defer detail.
\n\u201cI should say that this works for Craig because he can keep a lot in his head and is good with his conversations. From my perspective,
\nif a team can\u2019t keep track of which sentence in a use case they\u2019re implementing on a given iteration, they won\u2019t be able to keep track of the fractal expansion of very large user stories.\u201d<\/p>\n

Three essential factors<\/strong><\/h3>\n

In Cockburn\u2019s opinion, three things are really important in any project: vision, size and context:<\/p>\n

Vision<\/strong><\/h5>\n

\u201cIt is crucial that every team member sees approximately the same end goal. This is more important on agile projects because they write down less and leave more to tacit knowledge. Therefore, every project \u2013 agile or not, using Scrum or not \u2013 should have written down and posted in plain sight a short description of what the system is supposed to do and how it is supposed to help its users and stakeholders. Anything over a page long is too long.
\n\u201cIdeally, the vision or mission statement captures some emotional feeling to help the developers tell whether they\u2019re on track or not. For my new web site design, we\u2019re using, \u2018Get pleasantly lost in all the articles and content.\u2019 Our first user test produced the response, \u2018It\u2019s very nice and clean, but I can\u2019t see how to get pleasantly lost in here.\u2019 Because of the vision statement, our viewer knew immediately what to comment on, and we had a direct idea in which direction to make changes. Other ones might be like, \u201cSlide the buyer effortlessly along the conveyor belt to finishing a purchase\u201d, or \u2018Ensure the nurse NEVER gives a patient the wrong medication.\u201d<\/p>\n

Size<\/strong><\/h5>\n

\u201cEveryone has an idea of the order of the task at hand, whether this is going to be a 10 work-month project or a 250 work-month project. All too often with agile projects, I see a ceiling line that rises faster than the programmers can work. This makes the sponsors nervous and the programmers depressed.
\n\u201dI\u2019ve written that I like use cases because they reveal the size and shape of the product. If you\u2019re not using use cases, go for some other technique that will hint at the approximate size of the final system, so the sponsors can make appropriate funding and staffing plans.\u201d<\/p>\n

Context<\/strong><\/h5>\n

\u201dThe programmers, UI designers and testers know how each product backlog item, sprint item or user story fits\u00a0in the work or operation of the user. This context helps them make many small design decisions along the way, or even challenge feature requests.\u201d<\/p>\n

Use Case & User Stories \u2013 a pros & cons approach<\/strong>
\nUse cases and user stories serve fundamentally different purposes, and so in some sense it makes no sense to compare them:<\/p>\n

\u2022 The purpose of a use case<\/strong> is to describe the black-box behavior of a system as it interacts with the outside world \u2013 not just with the primary user, but also with other systems. A use case is a record of decisions made about the behavior of the system under discussion. Use cases primarily serve the user and business community. These people have long suffered from not knowing what they are going to get. Use cases help with that.Programmers sometimes don\u2019t like use cases because they are user-centric and call for behavior that crosses programmers\u2019 assignments.<\/p>\n

\u2022 The purpose of a user story<\/strong> is to mark \u2013 for later expansion \u2013 requests for system functionality. A user story is a token or marker that gets moved, expanded, annotated as the request gets handled. It is not a requirements document, it is not a record of decisions made, and it is not a description of system behavior. It is always just a marker. User stories primarily serve the developer community. These people suffer from having to split up requirements documents into tiny pieces to spread among themselves. User stories can be split small enough to assign to single developers or development groups.<\/p>\n

With these two purposes in mind, the pros and cons become quite clear, and are naturally opposing as shown to the right.<\/p>\n

USER CASE<\/h4>\n
    \n
  • Presents a clear description of system behavior.<\/li>\n
  • Records outcomes of discussions<\/li>\n
  • Provides discipline for “completeness” and look-ahead, and can be used to get a good handle on the size of the system to be developed and reduce the number of surprises along the way.<\/li>\n
  • Has a “shape” showing all behavior around a system request\u2013 this serves the user and business community well, so that people can more easily see the implications of what they are asking for.<\/li>\n<\/ul>\n

    USER STORY<\/h4>\n
      \n
    • Short (just a sentence or a phrase).<\/li>\n
    • Can be used to mark needs outside pure functionality \u2013 data enrichment, usability improvement, even internal work items for the team.<\/li>\n
    • Easy to write on an index card; sets of them can be manipulated in 2D on the wall to indicate priority and spans of behavior across actors quite visibly.<\/li>\n
    • Can be split into smaller and smaller pieces; a complete user story can fit into any size of iteration.<\/div><\/li>\n<\/ul>\n
      \uf0cc Presents a clear description of system behavior. \uf0cc Records outcomes of discussions \uf0cc Provides discipline for “completeness” and look-ahead, and can be used to get a good handle on the size of the system to be developed and reduce the number of surprises along the way. \uf0cc Has a “shape” showing all behavior around a system request \u2013 this serves the user and business community well, so that people can more easily see the implications of what they are asking for. \uf0cc Short (just a sentence or a phrase). \uf0cc Can be used to mark needs outside pure functionality \u2013 data enrichment, usability improvement, even internal work items for the team. \uf0cc Easy to write on an index card; sets of them can be manipulated in 2D on the wall to indicate priority and spans of behavior across actors quite visibly. \uf0cc Can be split into smaller and smaller pieces; a complete user story can fit into any size of iteration.\u001f- Presents a clear description of system behavior. – Records outcomes of discussions – Provides discipline for “completeness” and look-ahead, and can be used to get a good handle on the size of the system to be developed and reduce the number of surprises along the way. – Has a “shape” showing all behavior around a system request \u2013 this serves the user and business community well, so that people can more easily see the implications of what they are asking for. – Short (just a sentence or a phrase). – Can be used to mark needs outside pure functionality \u2013 data enrichment, usability improvement, even internal work items for the team. – Easy to write on an index card; sets of them can be manipulated in 2D on the wall to indicate priority and spans of behavior across actors quite visibly. – Can be split into smaller and smaller pieces; a complete user story can fit into any size of iteration.<\/div>\n","protected":false},"excerpt":{"rendered":"

      Requirements Management has for a time been a hot topic within the Agile community, and a religious war has seemed imminent between the followers of user stories on one side and use cases on the other. The rebelyell of the user story-buffs have often been \u201cout with the old and […]<\/p>\n","protected":false},"author":32,"featured_media":316,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22,59,83,14],"tags":[6,29,25,27,28],"_links":{"self":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/228"}],"collection":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/comments?post=228"}],"version-history":[{"count":19,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/228\/revisions"}],"predecessor-version":[{"id":1086,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/228\/revisions\/1086"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media\/316"}],"wp:attachment":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media?parent=228"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/categories?post=228"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/tags?post=228"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}