Applying Use Cases in Agile: Use Case 2.0, Slicing and Laminating
To incrementally develop and deliver products using agile software development, requirements are gathered and organized into a product backlog. A requirement technique that is used in agile software development is use cases. Some techniques to apply use cases for managing product requirements in agile are use case 2.0, slicing and laminating.
Shobha Rangasamy Somasundaram and Amol Sharma wrote a blog post about can formal requirement methods work for agile in which they compare the usage of requirements between waterfall and agile software development:
In traditional software development or waterfall process, the following methods are used during the requirements phase - brain storming, questionnaire, modeling, prototyping, observation, focus group, survey, reverse engineering, interview, document analysis, workshop for joint application development (JAD) - collaboration & domain model creation. In waterfall, requirements are sourced from the client, the BA and the product owner, wherein, they interact and prepare the final requirements document. Once the requirements are finalized, they are conveyed to the development team.
(…) requirements in agile are no longer committed to the beginning of the project or limited to a few individuals, but are a perpetual driver for the entire software development lifecycle. Agile does not prescribe any one way to document the requirements, the focus is instead on "just enough" documentation. Details are discovered and unfold slowly only when they are required. The monolithic dedicated "requirements stage" is broken and dispersed, that it now becomes omnipresent, with the same traditional analysis methods, performed throughout the lifecycle.
In their blog post Shobha and Amol provide a detailed description on how to combine roadmaps, use cases and user stories to manage the product requirements.
Andy Hayward explored different requirement techniques in a series of blog post. In when to use user stories, use cases and IEEE 830 – Part 2: Use cases he mentions several use case formats:
Use cases can be written in a highly formal format to describe the process extremely precisely, or in a simple paragraph format, what Alistair Cockburn described as a “Use Case Brief”, which is slightly more detailed than a User Story, and there are many variations in between. This gives the analyst a broad range of options to fit her use cases to the project need. Unfortunately, most organizations enforce a standard template for use cases which limits this flexibility.
Breaking down use cases into smaller parts can be difficult as Andy explains:
The problem with use cases is that they usually encapsulate a lot of requirements into one large chunk of information. This makes it hard for development teams to estimate the use case’s complexity and plan their work, and hard for the business to provide a meaningful estimation of value or priority. It’s possible to break each use case down into a list of ‘scenarios’ that describe each possible path through the steps, but if you’re doing that much additional work you might as well write “The system shall” in front of each scenario.
- Describe exactly what a software system must do
- Group parts of the requirements together for broad-brush scope management
- Slice the requirements to create well-formed product backlog items and drive iterative development
- Change the priority of what the customer wants at any time
- Produce a simple visual model, and meaningful requirements, that are understandable to developers and customers alike
- Realize the benefits of iterative and backlog-driven management practices such as Scrum, and the IJI Iterative Essentials
- Capture their requirements just-in-time, and in just enough detail, to support their business goals.
You can do use case slicing in agile to incrementally develop and deliver products:
The Use-Case 2.0 Essentials practice starts by finding actors and use cases, and selecting and prioritizing the parts (slices) of the use cases to be developed. It continues by detailing the use-cases slices and more importantly their tests, and then implementing software to meet the tests. It concludes by executing the tests, tracking progress in terms of verified, working software and feeding back the results in order to handle change and better support the team.
[A skinny system] has all significant paths through the use cases (or scenarios); it has all significant subsystems, components, classes, nodes. Usually this skinny system only includes 5-15% of the final code, but enough to demonstrate that the significant elements work. And most important, we know that this skinny system can grow to become the complete system.
In the blog post improving user stories with use cases Richard Schaaf described how use case 2.0 can help to manage the product requirements with use cases. According to Richard, the problems that organizations have with user stories have to do with process that is used to define them:
The issue here is (..) that it is really hard to write User Stories in such a way that they really help and are useful in the long term. What we need is not a replacement for User Stories, but a better way to come up with them.
Quite often, the Product Backlog degenerates over time and this leads to real problems for the teams. If you want to have a really successful Agile organisation, you really need to focus on the process of User Story generation.
He suggests using use case slices to define your user stories:
A use-case slice is a collection of front-to-back flows through a use case, including the associated test cases that is of clear value to the customer. A front-to-back flow is called a use-case story.
Richard explains how you can break down a use case into use case stories, and use them to define use case slices which can be the user stories that we need for our product backlog:
If you did your use-case modelling right, each of these use-case stories has a certain value. A use-case slice is then simply a selection (one of more) of these use-case stories, plus a number of test cases that should be met.
A use-case slice defined in this way meets all the criteria for being a User Story. After all, we know who it is for (the initiating actor), what is requested (the use-case stories and test cases) and the value (derived from the way the use case was constructed). Thus a use-case slice is a User Story and can be used as an item on the Product Backlog.
Some of the advantages of using use case slices according to Richard are:
By putting the use cases in a central position, the focus is always on the entire system.
The level of detail is a discussion item early on, so we end up with just enough detail, just in time.
The definition of a use-case slice ensures that each User Story is a front-to-back Story that actually focuses on value.
However, the language is backwards, we are not starting with an elephant, and deconstructing it into slices. We are starting from nothing and constructing the elephant. Having a pile of elephant slices does not produce an elephant. What we want to discuss is the sequence of laminations that produce the best-semblance of an elephant in the least time.
Laminating starts with a walking skeleton:
A walking skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.
How can a walking skeleton of a software product or system look? Alistair provides some examples:
What constitutes a walking skeleton varies with the system being designed. For a client-server system, it would be a single screen-to-database-and-back capability. For a multi-tier or multi-platform system, it is a working connection between the tiers or platforms. For a compiler, it consists of compilation of the simplest element of the language, possibly just a single token. For a business process, it is walking through a single and simple business transaction (as Jeff Patton describes in the technique Essential Interaction Design, later in this chapter).
From the walking skeleton you start to laminate outwards as Alistair described in the A-B work split, feature thinning and fractal walking skeletons:
I put part of the feature F on the steeply rising part of the curve, and said, “Just do enough of the feature to be sure you can do the rest of the feature without trouble (that’s the A part). Now defer the rest of the feature F (the B part) to the tail of the curve. You know you can grab for B at any time.
Alistair provides several strategies on how you can do the A-B work split to determine and prioritize thin features that you can use to develop your product incrementally:
- The A-B work split says to implement just enough of a feature to be sure you can grab the rest of it at any time.
- Jeff Patton’s Feature thinning does something different — he implements enough of the feature to argue that it really works, just isn’t very glossly (like having ordinary brakes on a car, but not anti-lock brakes).
- The Walking Skeleton strategy says to get the barely minimal (sub-minimal?) functionality running to establish connections between the parts. Jeff recently expanded that to having a mini – walking skeleton for each story (http://agileproductdesign.com/blog/the_new_backlog.html). Gery Derbier wrote me with the phrase recursive or fractal walking skeletons to describe this, a nice phrase. He says they use them on his project and they like them a lot. I would think so —- It’s vaguely related to the A-B work split and hence has risk reduction characteristics. I’m not sure if Jeff has feature thinning in mind with his mini (fractal) walking skeletons, but I think they’re possibly slightly different from each other.
How do you manage your product requirements with use cases: Use Case 2.0, slicing, laminating, or in another way?
Let's find the common ground instead of just what is different!
Some points for discussion:
1. Are we talking about fundamental differences between slicing and laminating? IMHO no, as you also allude to in your article. In both cases there are good ways of doing slicing/laminating and bad ways. To find good slices we start from the skinny system. As I understand it, to find good laminates, you start from the walking skeleton. Slicing as you do when you slice a sausage won’t produce good software. Slicing by finding value flows gives good slices.
2. Is there a fundamental difference between a skinny system and a walking skeleton? Again, IMHO no they are basically trying to do the same thing. We selected the term skinny system to make sure that it was a system that could execute, but with less muscles (10-15% of the completed system). It is still important to build good skinny systems, as it is to build good walking skeletons.
3. Is this discussion primarily a discussion on syntax and less a discussion on semantics? IMHO, yes I think so. The semantic differences are small. When it comes to syntax, having designed languages – both programming and modeling languages - for many years, I have adopted classical language design practices. Select keywords that are neutral to goodness; what is good may vary from application to application, from time to time, etc. For instance you may have good components or bad components, but still components. In some cases you may have to take a chunk of code and make that chunk a component, for instance because you reengineer a legacy system. Thus keep the syntax free from goodness values. As a compromise, I would be happy to say that a good use case slice is found by laminating what needs to be built.
From my past work I have tried to first find what is a common ground and then find what is different. There are most likely some differences, but if we don’t find what unifies we cannot move forward and support the users. For instance, UML was such a case. Before UML we had lots of notations and a confused user world. What should a user select? Booch, OMT, OOOSE, etc…. Now, there is no other competition to UML than not using it, and that is fine. I think we should be able to do similarly here: identify what is a common ground and then add the differences as variants on top of that common ground. OK, I will stop here.
At the least we are clearly in agreement that use-cases is a good strategy for working with requirements and test in an agile way.
That is a good start, right?