Udostępnij za pośrednictwem

Identifying your vertical story skeleton

  • Artykuł

I’ve been leading an agile team for a while now, and I thought I would share some of the things we’ve learned. This one is about vertical slices, and learning how to do this has made the team more efficient and happier.

To make this work you need a team that is cross-functional and has the skills to work on your whole stack (database/server/ui/whatever).

As an example, assume that the team is working on the following story as part of a library application:

As a authenticated library user, I can view the list of the books that I have checked out.

The team discusses what this means, and here’s what they come up with:

  1. Authenticate the current user
  2. Fetch the list of book ids that are checked out by that user
  3. Fetch the book title and author for each book id
  4. Display the nicely-formatted information in a web page

My old-school reaction is to take these four items, assign each of them to a pair, and when all of them are done, integrate them together, and the story will be complete. And that will work; lots of teams have used that approach over the years.

But I don’t really like it. Actually, that’s not quite strong enough – I really don’t like it, for a bunch of reasons:

  • It requires a lot of coordination on details to keep everybody in sync. For example, changes need to be coordinated across the teams.
  • We won’t have anything to show until the whole story is done, so we can’t benefit from customer feedback.
  • Teams will likely be waiting for other teams to do things before they can make progress.
  • The different areas will take different amounts of time to finish, so some people are going to be idle.
  • Our architecture is going to be a bit clunky in how the pieces fit together.
  • It encourages specialization.
  • Nobody owns the end-to-end experience
  • Integrations are expensive; when we integrate the parts together we will likely find issues that we will have to address.

The root problem is that the units of work are too coupled together. What I want is a work organization where the units of work are an end-to-end slice, and a pair (or whatever grouping makes sense) can go from start to finish on it.

That seems to be problematic; the story describes a simple business goal, and it’s unclear how we can make it simpler. We *need* all the things we thought of to achieve success.

This situation blocks most teams. And they are right in their analysis; there is no way to be simpler and to achieve success. Therefore, the only thing that might work is to redefine success.

That’s right, we’re going to cheat.

This cheating involves taking the real-world story and simplifying it by making it less real-world. Here’s a quick list of ways that we could make this story simpler:

  • We don’t really need the book title and author, so we redefine “list of books” to “list of book ids”.
  • The display doesn’t have to be nicely formatted, it could just be a list of book ids on a web page.
  • The display could even just be the results of a call to a web API that we make in a browser.
  • We could build the initial version as a console app, not as a web app.
  • The story doesn’t have to work for every user, it could just work for one user.
  • The list of returned books doesn’t have to be an actual list of checked-out books, it could be a dummy list.

This is just a quick list I came up with, so there may be others. Once we have this list, we can come up with our first story:

As a developer, I can call an API and get a predefined list of book ids back

I’ve taken to calling this a “skeleton story”, because it’s a bare-bones implementation that we will flesh out later.

We will go off and implement this story, deploy it as a working system, and – most importantly – verify that it behaves as it should.

Getting to this story is the hard part, and at this point the remaining vertical slices are merely adding back the parts of the story that we took out. Here’s a possible list of enhancements:

  1. Fetch the list of book ids for a predefined user
  2. Fetch the list of book ids for a user passed into the api.
  3. Display the book ids in web page
  4. Display a book description instead of just a book id.
  5. Make the web page pretty.

These will all be converted to stories, and we will verify that each one makes the system more real in a user-visible way. They aren’t perfect; some of the slices depend on the result of earlier slices, so we can’t parallelize across all 5 of them, and we will still need to have some coordination around the changes we make. These issues are more tractable, however, because they are in relation to a working system; discussions happen in the context of actual working code that both parties understand, and it’s easy to tell if there are issues because the system is working.