Why user stories and the thin slice are a lie…
Provocative title, yes? Well, give me a moment to explain and I think you’ll understand.
In Agile there is lore about the “thin slice.” The idea is that you build just what’s needed to implement the current user story. You “slice through” each level of the solution architecture and implement the user story.
I've had real problems “thinly slicing” the solution architecture along user story boundaries. The primary problem is that the user story is focused on functionality delivered to the user, but a modern software project requires a lot more work than just the user-visible functionality.
Software development is typically 15% to 25% of the project budget. This often strikes developers as unbelievable — especially the prima donnas. But it’s historically been true and it certainly isn't far off for most projects. Let’s be generous and say 25% of the project is software development.
If only 1/4th of the project involves software, then having a software development methodology that focuses on the user stories may not serve you best.
“But if we don’t focus on the software we’ll create waste!” Okay, let’s get waste off the table. A lot of the non-software things are NOT waste, even on a “software” project. Creating copy, content, assets, plans, budgets, resourcing, marketing, photo shoots and processing, and infrastructure are NOT WASTE. You cannot play the waste card just because you are software-centric.
One way to avoid waste is to constrain the choices available for a solution. This is true for many projects, not just software. In software, the primary mechanism for constraint is called, “architecture.” You specify a list of constraints and structures and goals which create the context in which you’re going to build the software. Many Agile projects don’t bother to architect their solutions.
If you don’t bother to architect your solution, you are essentially “cutting slices” out of thin air. What exactly are you slicing thinly? An Agilist would say something like, “You may be thinking of it wrong. You are not ‘slicing’ so much as only building what you need for this story.’” But in software we learned long ago from Parnas (1972 in fact) that if you don’t control the structure of your software (the architecture) it will come to control you. Spaghetti code is tangled precisely because there were too few constraints, too little architecture to keep the code in line [and of course clean code requires some developer discipline].
Agilist often skirt the architecture issue by saying things like, “the user story is a container for a conversation” and point out that through having these conversations you will discover what needs to be done for your thin slice. I don’t buy it. The people having the conversations — the developers — are not trained architects experienced in the modularization that Parnas discussed.
The user stories are analyzed too late in the process to properly discover and plan. The user story is too focused to reveal the commonality required for modularity to be identified and the structures created.
Typically user stories are assigned to software developers or sprint teams that are focused on the software. Software developers often have disdain for project planning. Putting software developers in charge of protecting the project plan (and all of the non-software related activities that are required) is what author Alan Cooper called “letting the inmates run the asylum.”
Producing the project plan based on the list of activities spanning the entire project helps create a comprehensive plan that involves everyone and shows the true demands placed on the team at large. This plan should show the activities listed in the order of their dependencies, including the software activities and the non-software activities. This produces the so called, dependency graph of activities for a project. It tells you your critical path and the order in which the activities need to be completed.
Let’s say that you have an activity graph like this one:
In this graph, activity A2 depends on activity A1. Activity A3 depends on A1 and A2 and so on. We must complete A11, A10, A06, A04, A03, A02, and A01 before we can finish A12.
Suppose that this graph contains all the identifiable activities for the entire project and that when you get to the bottom the project can be considered done. If that’s true (and I think it is) then we can think of user stories as the integration of the finished activities required to complete a user story.
The notion of the thin slice would be replaced by the dependency graph as shown here:
The graph of activities is NOT the same as graphing the tasks identified within a user story. It simply doesn't work that way. Too many of the activities in a project (around 75% of them) are not related to software. If you take a software-centric view you will be missing much of the picture.
There are several things to note about this dependency graph with user stories.
First, as I've drawn this, the user stories are bottom heavy and the activities are top heavy. That does not mean you need to complete all the activities before finishing the user stories, but it is likely to be the nature of things that more and more stories will be developed toward the bottom.
Remember, you now have the opportunity to identify the critical path and work along it, meaning that your project can accelerate it’s delivery.
Second, we have now sliced the functionality required for each user story without focusing on the so called “thin slice.” Anyone that has tried to do “thin slices” on a real project (with a budget and a deadline) knows that it is deadly to productivity because it forces too much rework. Talk about waste! Even very clever teams get bitten by rework. In the graph above, US1 (user story 1) is a combination of A8, A6, and A10. Your “thin slice” is to detect when A8, A6, and A10 are done and confirm that the story can be closed.
Working on a project in this manner also allows you to identify the critical path and resource accordingly — something that is extremely difficult, if not damned near impossible, if you take a user story focused view of your project.
I’m suggesting this technique for projects that have a budget and a schedule (in my experience that has been all projects). If you are working for a start-up or on maintenance, you may not have a clear set of requirements and may not be able to build the activity graph.
Last, this is how the work happens anyway, only we fight it. And we lose valuable information by not acknowledging the relationship between activities and user stories. When we start an Agile project we usually have to fight against desire to do “technical sprints” or a humongous and overloaded “sprint 0 (zero)". This is because we naturally want to fill in the top half of the dependency graph. We can embrace this notion without becoming top heavy and “waterfall.”
Using the above method, the user stories become integration points. This is a technique for showing the user stories in the big picture of a professional project plan, not the other way around.
