Design with User-Stories - the curse of the technical/UI story !
No Technical or UI Stories
I’ve been hearing lots of conversations or read posts lately where people mention “technical stories. We even can spot some of these “technical stories” in the invaluable Scrum and Xp From the Trenches, p9 . And reading this thread on agile UCD made me react on this concept of “UI stories” ! To me, it makes the same feeling as “technical stories” do : it makes me shudder !
As I see it, a story is something across all layers that “provides some value” to a user. Let’s rephrase it : “something that brings an actor using the software closer to (at least one of) its goal(s)”. Stories should stay “above the water”, as mentioned in Cockburn’s Writing Effective Use Cases . They should avoid dealing too much with the solution and focus on dealing with a problem the user has.
User-stories should stay “above the water”
Some people write “technical stories” to creating a new table in a DB or add a button. These are not stories, but merely tasks that need to be done in one solution to such stories. Actually, I consider it pointless to talk about anything other than “User(/actor) Stories” (actor because stakeholders, admins, deployment and other software also interact with the product). Since Kent Beck coined the term “user story” and thanks to Mike Cohn’s book spreading the use, working with stories was imho a great step as it brought back some focus on the user side, away from “the system shall…”. Let’s not forget that.
That being said, it’s true that some stories have a greater focus on usage (and thus the UI), some on a complex business logic, some involve technical feats underneath… But all should be user stories.
USER stories
What are user-stories ? It’s not just about using flashy post-it notes or cards, to prevent us from writing lengthy specs to bury somewhere. It’s not just about doing things fast and dirty. It’s not a matter of dividing the work to come in “sprint items”. It’s a matter of design.
User Stories should be the focal point (as illustrated in this article about the product owner), enabling communication between all perspectives : UX, design, dev… Here I’m using the term “design” on intent, refering to its two perspectives, as in “apple products have a great design” and “a well refactored oo design”. These two perspectives are not opposite. They are the two sides of the same coin.
User-stories should be the focal point between all perspectives
Design is finding a solution to a problem. User-stories enable us to have conversations (as in cards, conversation, confirmation by Ron Jeffries) about design : how do we solve things for users ! They are anchors for conversations
So, how we phrase user-stories, how we slice them (like Maven and Motley), how we picture them should not be dealt carelessly !
Organizing stories
First, how do we picture and organize them ? For that, storymaps are a great concept that have been gaining popularity lately thanks to InfoQ, initially brought forward by Jeff Patton and Todd Warfel through his Task Analysis grid. Whereas a classical backlog is a 1-dimensional list of stories, storymaps help you organise them in two dimensions. On a horizontal axis, the workflow of user activities. On a vertical one, the necessity of stories, from bare necessities to luxury.
Do you try to avoid building your application in a horizontal component-layered structure one component at a time, to favor a vertical one providing some value to the user across all layers ? Just step back and there you can see the vertical slices of your application. This helps a lot ! You can still have horizontal slices but they have a different meaning. You use them to iterate and refine features.
User-stories are organised in a storymap
This provides a big picture of features for a whole product, enables you to outline a functional roadmap. I also use that to visualize and litterally pinpoint risks… I’m curious of your experience : any other usage of your storymaps ? The backlog is dead : long live the storymap !
Phrasing stories
Let’s focus a little about specifically on how to phrase them. So, my user-stories don’t look like those for instance of the story card template described by Scott Dunn, or like the standard “as a
You don’t have to state why its’s valuable to the business because you only write one when answering one need of an actor toward its goal. Should we begin by considering technical constraints, as usual from an architect perspective, as most IT departments do ? My answer is a clear NO !
I prefer to see how technical constraints and risks map on the functional and incremental view of the product : the storymap.The order by which you pick up stories is made obvious through a storymap by outlining a release plan.
Dealing with constraints
User-stories should not mention the tool, that is the UI or the technical solution used : this should only feed the constraints, whether directly in the DoD (for the french crowd) (Definition of Done) or for specific stories. If it’s not obvious to you, yes UX (user experience) considerations should also appear in the DoD.
Constraints are for the validation part of User-stories
Any business rule/data requirement/whatever constraint (UX, performance, *ity) is specified in the validation part of the story. This should be succinct enough to fit in one or two lines of an spreadsheet cell. If not, work on stating clearly what is the intent behind and question that. When dealing with a business logic that is not straightforward, this is all transposed in some acceptance tests one iteration at a time, ready for discussion at sprint planning time. Of course, there are some issues uncovering some potential complexity that have to be anticipated. Anyone remembers the work on software reuse from the 90’s and axis of variability ? Discussions on design again !
What process do I follow ?
So how do I use user-stories ? I first define the actors and their objectives, which is a first take at personas, that may be refined later. Other actors or roles may be later added or divided into more specific roles or profiles, but franckly, the few ones appearing at the first pass will already provide you lots of insights.
As all cards refer to at least one actor whose goal has been stated, the value doesn’t have to be stated for each story : away the “in order to” from the canonical from. They can thus focus on the action part of the story. A little step toward literally drawing stories : a symbole or picture in a top corner of a card is a good way to do that. Directly using names of personas is a very good idea that I’ll use next time ! Any card that doesn’t provide and fit in an actor’s goal will be thrashed, it’s as simple as that. They are grouped into activities, ordered by necessity, may be sliced with varying “conditions of validation” from a minimal service to the full monty. They are then estimated on a “just-in-time” basis for the next release, that is one or two iterations in advance.
User-stories enable us to have conversations about design
All this is subject to lots of conversations. The cards may be rephrased as the intent behind the stories becomes clearer. As the solution for a problem of a user becomes clearer. As the design becomes clearer.
I emphasized the importance of user-stories, as a support for conversations for design. But knowing that we’re visual animals, I’m also convinced (thanks to Dan Roam talks ) that we must use more our visual potential. Crafting “Product Boxes” is a one step toward that. Appart from traditional oo diagrams and other potatoids, I’m convinced that we should draw more to support our designs.
Any examples of what and how you draw to support your stories / your designs ?
12 August 2009 à 06:48
Excellent post. I like that you exposed the fallacy of technical stories (i.e., being tasks rather than stories). And I liked the reminder of Cockburn’s “User-stories should stay “above the water””. Your process is usage-centric and user-centric - focused on user intent, activity and actions
(I wish I had read your post before I blogged about using Jeff Patton’s task analysis / story mapping.)