USER STORIES and use Cases-don ' T use BOTH

We ' re in Orlando for a working session as part of the Core Team building BABOK V3 and over dinner this evening we got to D Iscussing the relationship between user stories and use cases (it wasn ' t the only thing we discussed, we is also a social Group;-)).

We noted with concern that there has been a number of recent discussions (client, articles, blogs and general industry) O F using both User Stories and use Cases at the same time in Agile projects. This seems to us (with general agreement around the table) to be both a waste of effort and actively against the Agile PHI Losophy of doing the simplest thing that would work and deferring the detail until just ahead of when the component of the Product would be built.

We would like to outline the basic differences, considerations and risks of using this approach. Even it is seems-be a trending topic, we-would like-to-fill the gap in addressing beyond the trend and move towards the Practically and risks of using use Cases on Agile projects.

DIFFERENCES and similarities

So what is the differences and similarities between User Stories and use Cases, and if do we recommend using the differ ENT tools?

Use CASES

A use case was "an end-to-end sequence of interactions between an actor and a system that yields a result of observable Val UE to an actor, usually the instigating actor. Um, so why does that actually mean? Generally a use case (the textual description, not the stick figure diagram) is written as a flow or sequence of steps in The format

Actor does something
System does something
Actor does something else
System does something else
...

A use case was made up of the one main flow and a number of alternate and/or exception flows some of which can branch back to T He main flow.

Now use Cases is by nature fairly detailed-they describe the steps in a activity and the points in the flow where thin GS can change. To produce a useful (can is given to someone to build from) use case you need to define the set of interactions in quite a Bit of detail, need to understand what's the business rules is that govern the activity, the options that the actor WI ll has available to them when undertaking the activity, the ways things could go wrong and what bits of information is n Eeded in the flow of interactions. Need to spend quite a bit of time and effort analysing the activity and producing the document. This was Bduf-big Design up Front which is the antithesis of Agile.

USER STORIES

User Stories were originally a reaction to this big up front thinking. Whenkent beck defined extreme programming  (XP) He came up with the concept of a User stories as a tool to SUP Port the iterative and incremental approach which is inherent in all the Agile methods. mike cohn went on to WRI Te A book which explained what User Stories is and how they is used in Agile projects. In addition to these Two, jeff patton publicized the technique of story mapping to show how User Stori ES can is used to cover the breadth and depth of functionality needed in a product.

The key to writing good User Stories are to understand, the intent is not to provide the detail early on a projec T, but to provide a framework where the detail can be added as it's needed, just enough and just in time. Drawing on the work of Beck, Cohn and Patton and many others the generally accepted approach to producing User Stories and Using them to guide the development of the product follows a decomposition approach.

The decomposition comes in the form of a story map. The beginning of a story map was defining the Backbone stories–the key User activities or Tasks which need to be accompli Shed to does the work of the product, the large discrete chunks of functionality which need to being delivered to being able to SA Y we have solved the problem. These large chunks is often referred to as Epics (a big stories;-)), they equate to an elementary business process, Someth ing that is the done in one place, at one time, by one person. Comparing this and use Cases, this would is the result of the use case survey-a list of the discrete elements of the PROD UCT, goals of the actors.

When building a story map, these Epics is normally laid out in a single row showing the logical sequence and handoffs bet Ween the steps in the process. Visually these Epics'll be written on a different colour card to T e User Stories which would come later.

Image:an Example of a story map–epics in green along the top

Epics can be put in sequential order along the top (if sequence was appropriate, which it normally is).

The next step in the stories map is to populate the map with the User Stories that fall under the Epics. Each of the user stories is a small, discrete piece of functionality, have value to some User of the product and are a decomposit Ion of the Epic above. The most common format for writing User Stories are "as a (role) I want (feature or capability) so this (business value to Be delivered) "-

• As an internet banking customer I want to list my account balances so I can understand my financial position.
• As an internet banking customer I want to list transactions on a account so that I can check the detail

The three elements is important-knowing who the stories is for helps ensure we build a useable product and what the function Ality is this is needed and the value which'll be derived from have that functionality enable us to make good priority decisions.

Priority based in business value is very important to defining User Stories. Knowing the value from a stories enables us to make good decisions on the sequence of work-building the most important Business value components first and getting feedback early rather than trying to build everything at once are inherent to A Gile.

The User Stories is the orange cards in the image above.

Priority and SEQUENCE shown in the Map–identify the MVP

One of the benefits obtained by building a story Map, shows the logical flow of activities (from epic to epic along th e top) and the discrete elements of those Epics vertically down the page are the ability to clearly see both sequence and P Riority. Stories that is higher up on the map is more important (needed sooner) than those lower down.

The prioritisation and sequencing approach enable the discovery of Theminimum viable Product (MVP) –those elements which Need to being delivered to provide the opportunity to learn and adapt the product based on feedback from real customers/users . Finding the true essence of the product and getting that to the hands of real customers (probably just a small subset in Itially but enough to get feedback to validate, the assumptions being made in the development of the product).

In a Real-world internet banking example, the very first version of the product which is put in production had the Abilit Y to log on and to list balances and this version were used by the project team and a small group from within the bank. Have this "walking skeleton" built and put into production validated the architecture of the product, identified a Numbe R of unexpected challenges with the deployment process and gave the team feedback about their design philosophy which Enab Led them to make some significant changes when they were cheap and easy to do.

The ELEMENTS of A USER Story

In He book, Mike Cohn says that a User stories has three C ' s-the Card, the conversation and the confirmation. The Card is the initial User stories, written on an index Card or PostIt note. This is deliberately short and devoid of detail. The intent is to defer the detail until later in the project, and just ahead of when this piece would be delivered. The detail is established through the second c-conversations. As the project progresses and elements are delivered there would be a number of conversations that result in clarity of und Erstanding about "actually needed to deliver" the value identified in the "User story."

The final C is Confirmation-these be the acceptance Criteria for the User story-the details which would enable the Customers and the technical team to agree, "If this story meets these criteria it's done". This is the detail which are all too often left out in bad Agile projects ("Tragile"). This detail needs to being agreed to, and it would contain whatever is needed to enable the delivery of this component of the Product. The key difference between Agile and other approaches are when we produce this detail. In an Agile project This'll be produced collaboratively with the customer representatives just ahead (a couple of hours To a couple of days) of when the piece would be built.

The most common format for these acceptance criteria are the <given><when><then> structure of acceptance Test driven Development. Each user story'll has a number of acceptance criteria and may also has other elements which would help ensure the righ T thing is Built-these could include screen mockups, technical notes, models such as class diagrams and whatever the tea M needs to enable them to deliver the business value.

Examples (for the list account balances user stories)

Given the customer has a credit account and a savings account
When they has logged in successfully
Then the both accounts would be listed on account number order (account No, Name, Balance, Available Funds)

Given the customer has no accounts
When they has logged in successfully
Then a message indicating that there is no accounts to show'll be displayed

Given the customer has twenty one accounts
When they has logged in successfully
Then the first twenty accounts'll be listed on account number order
and a Next Page option would be enabled

Given the customer has twenty five accounts
And they has logged in successfully
And they is on the first page of the list
When they activate the Next Page button
Then the list would be cleared
And the list would be populated with the last five accounts
And the Previous Page button would be enabled
And the Next Page button would be enabled

Gojko Adzic ' s book specification by Example provides a excellent reference on how and when to produce acceptance criteria .
Ultimately the acceptance Criteria would be proven through a set of test cases (ideally automated) which show that the Prod UCT works as needed to deliver, the business value.

REDUCE Waste and be RESPONSIBLE

Again, the key to reducing waste and rework are to defer this detail until just ahead of if it is needed, rather than try ing to clarify it all up front. Things would change over the life of the project and deferring the detail makes it cost-effective to adapt to this change.

However–taking This just-in-time approach are not a excuse for poor architecture or bad design. Early on the product development it's important to set clear architectural guidelines, design principles and deal with What Philippe Kruchten calls the "architecturally significant non-functional Requirements" –those aspects which would be Extremely expensive and difficult to refactor later. Note However that we say "guidelines" and "principles" –don ' t try-to-build the complete architecture-front, allow it T o be emergent inside the boundaries of these clear guidelines.

Traceability in USER STORIES

Hopefully it is clear from this description that User Stories actually has a powerful traceability mechanism built into t He design of the technique.

There is a cascading one to many relationship:

• A Role or Class of User derives value from one or many Epics
• One Epic could has many User Stories
• One User story would eventually has many acceptance Criteria
• One acceptance Criterion would have multiple Test Cases which prove it's working as expected

This traceability are enacted through the "so" component of the user stories, which ensures that every piece which are IM Plemented has a direct relationship-to-the-business value to being derived from that component/capability.

TIMING makes the difference

The key is the Timing-user Stories be deliberately abstract early on a project and would evolve over time on a jus T-in-time and Just-enough basis. This is because Agile projects expect and anticipate, change, and respond to this change by adapting the product to the Evol Ving Tsun needs. More User Stories'll be added, some'll be a dropped and our understanding of many to change as time progresses. The reality of today is inevitable, so trying to define the detail of all aspects of the U Pfront would result in lots of wasted effort and time as much of the work would need to be redone.

The story Map was a fluid and changing tool–as stories is completed they was removed, new ones added and change is ACCEP Ted as a normal part of the the the-maximise the delivery of value to our stakeholders and the organisation for whom the PR Oduct is being built.
The detailed acceptance Criteria for any User story would on being produced just ahead of when it'll be delivered, Maximizin G The amount of work do not do (one of the principles of the Agile Manifesto)

One of the mistaken and dangerous myths of Agile is that "agile projects has no documents", Haven reality is Agile project S has the documentation that's needed to ensure value are delivered, and nothing more. The philosophy is to defer work until just ahead of the if the output of the that work was needed (a concept inherent in Lean thi nking) and which is necessary to achieve the desired outcome (preventing waste from unnecessary effort a nd rework).

This was in stark contrast to use case thinking where the goal is to define in the various flows of the Tail of the requirements up front. This approach would inevitably result in wasted effort as the use cases would has to be maintained and updated as the Chang ing needs emerge. In agile we want to evolve the solution iteratively and incrementally as we learn based on feedback from real customers/us ERS, not rework the documentation and requirements.

COULD you use CASES INSTEAD of the USER STORIES in an AGILE PROJECT?

Theoretically yes–you could indeed use, Cases instead of User Stories to express the business needs. None of the Agile approaches is prescriptive about what you express the list of Capabilities/features the product must con Tain (What is Scrum calls the Product Backlog), however we see significant risks on trying to doing so. Use Cases miss the ' Why ' on the mark; They is not well suited to expressing the separate pieces of business value and supporting the iterative, incremental app Roach to developing the product–they tend to being monolithic and encourage an "any or nothing" from the Thinking vs. an ADAP tive evolutionary style of learning and discovering the solution together through quick build and feedback loops.

COULD you BUILD use CASES after developing a AGILE solution to DOCUMENT the REQUIREMENTS after the FACT?

Theoretically, yes ... however with the approach you had missed out on a critical technique in User Stories to guide C Onversations towards maximising value and minimising extra work throughout the development process.

Risks and dangers of use case thinking in AGILE PROJECTS

• Compromised innovation
  • Use Cases bring in a lot of detail before getting feedback on a built product. This cognitively brings user mind-sets to a predefined interaction and solution, negating the potential for further Inno Vation. The exploration and learning aspect is compromised and focus goes from solving a need to perfecting an already defined Sol Ution.
• Compromised timelines:
  • Too much detail before building compromises the benefits of time in the Agile approach. Spending time detailing out use Cases are spending time on "what" when we are should focusing on the why. Defer the what until just ahead's when it's needed
• Compromised Value:
  • Use Cases confuse the role of acceptance Criteria in User Stories and agile. Many teams is using use Cases as a alternative to creating acceptance Criteria for their User Stories. Acceptance Criteria evolve in levels of detail as builds iterate and evolve and more are learned together through the agile Process. This learning process was where the value lies as the needs is quite unknown before starting.

Conclusion

Many teams embarking on their Agile journeys is finding comfort in techniques used in the past for requirements Definitio N, particularly use Cases. Use Cases resemble user stories in + detail, and user stories were developed as a condensed technique to alleviate the Lack of why, use Cases, and to alleviate too much detail too soon when using a Agile approach.

We believe that User Stories and acceptance Criteria is the techniques aligned to deliver the benefits of the Agile Appro Ach and use Cases compromise and put the benefits of the Agile approach at risk.

Teams thinking about using use Cases should strongly consider looking at the methods and evolutions of defining acceptance Criteria (especially the <given><when><then> model) with many scenarios and levels of detail that Evolv E As feedback through the iterative cycle and delivering increments of the product as it evolves. Keeping with user stories (including stories maps & epics) along with well defined and evolving acceptance criteria would Meet the goal of leveraging the benefits of agile without putting timeline and value at risk.

USER STORIES and use Cases-don ' T use BOTH