Creating options by slicing features - #NoEstimates technique

Each feature (or story) in a product backlog contains many undiscovered options. By taking features as they are without slicing them into thin slices of functionality we implicitly commit to an implementation strategy. However, when we slice features we create options that allow us to pro-actively manage the scope of a project.

Let’s return to the IT Support Ticketing System project we discussed in a previous post. A feature like the one below will not allow us to manage the scope actively.

• As an employee I want to be able to submit issues to IT so that I can fix a particular problem that prevents me from working.

The feature above is what I would call a “binary” feature. Either the employee is able to submit an issue to IT or not. This simple feature can have large implications in terms of the amount of work required to implement it. Taking the feature above and breaking it down into several smaller features or stories will allow us to make decisions regarding the implementation order, or delaying certain parts of the implementation. Let’s look at an example:

• As an employee I want to be able to email an IT issue to the IT department so that I can have a fix for a problem that prevents me from working As an IT helpdesk employee I want to have a queue of issues to handle so that I know what items I should be working on at any given time.

By slicing the original feature in this particular way we unpacked the functionality under the term “submit issues” in the original feature into two different features: Email (replaces submit) and Queue of issues (replaces the receiving end of the submission process). We’ve potentially reduced the scope of the initial feature (no need to have a system to enter IT tickets, just send an email), and we’ve given ourselves the option to implement a solution based on standard tools. The two features we created allow for a solution based on email and a spreadsheet program with shared editing, like Google Docs.

These two stories could still be implemented with a full-fledged IT issue tracking system, but that is an option. Not a mandatory outcome of the initial feature. Slicing features into separate functional parts helps us actively manage the scope by creating different implementation options that are often implicit and non-negotiable when we have larger features in the backlog.

Picture credit: John Hammink, follow him on twitter

Another post in favor of another User Story format

Some time ago I wrote a post supporting the idea of a new template for the User Story. In that post I tried to explain why we should bring the "value" (because) clause to the fore, to make it the most important clause of the User Story template.

Then John Arrowwood commented on that post and made a reasonable argument to stick to the "old" (or traditional) format for User Stories.

This is a second post in defense of the new template, where I try to explain why the "value" clause in the user story should be brought to the fore, to be the most important clause in the User Story. Here's the template I propose:

• In order to "benefit/why/value"
  
• As a "user role"
  
• I want "feature/functionality"
  

Although I don't see any logical flaw in John's argument I don't agree with it. The reason is that in reality I don't see that people understand the ultimate goal of the User Story which is to justify every functionality in terms of what value it brings to the user.

No matter how much we stress the need to have the "value" properly described I don't see anyone (literally) using it. Normally the User Story writer will not understand the real "value" for the user before I do the 5 why analysis on the "feature" so that the person understands the deep reason why that "feature" is valuable to the user.

I also see that people don't spend anytime writing the "value" part of the clause, they tend to use banalities and obvious things. Writing an obvious "value"-clause delivers zero value when communicating the user story. Remember that it is the "unexpected" and "non-obvious" that actually delivers value, because it contains information that was not obvious to the reader.

Here's an example: everybody knows that as a user of Yahoo! e-mail client I want to save emails sent and received because I may want to return to some business-critical information later on, what not everybody knows is that as a Gmail user I prefer not to have a folder structure to archive old e-mails because it's easier to search than to create a folder system for archiving.

If you take as value the "archiving" then you will create a stupid folder structure for people to be able to "store" old e-mails. However if you take the "finding easily a relevant e-mail" as the value people are looking for, you may start to think twice and ask yourself if all users (all over the globe) are really librarians that think in archive-system terms. Guess not.

When you write a User Story start from the value. Always. No Exception. Ever. Start by asking yourself what does the user/customer really want to do. I mean really! (hint: seldom customers are happy with just using your product, they normally want to accomplish something!)

The value part of the User Story should be the non-obvious part of that value, the obvious explanation for a User Story does not deliver any information to the person downstream that will read the story and have to implement it.

I don't expect everybody to understand this, then again I don't expect all companies to create great products.

Learning to be better is not mandatory. Then again, neither is survival...

For a better format for User Stories

Karl follows up on a post by Liz Keogh about the fact that User Stories need to have a different format. The original format was:

• As a <customer role>
• I want <functionality>
• because <customer value explanation>.

Before explaining the new format let me dissect a little bit this old format. Why is it wrong? Clearly the most important thing we want to achieve with the User Story format is "focus on the customer", which for us means focus on the value that customer needs to achieve with the functionality we are developing. So the question is: why is the most important thing the last in the current used user story format?

When teaching User Stories I've started to teach a "thinking model" (credit to Pekka Usva for pushing me to do this). It goes like this: whenever you start writing a user story always, always start by writing the goal (because...) part first. Never, ever write the functionality (I want...) first.

That's why Karl's post clicked: it makes perfect sense to change the format of the User Story. Therefore I hereby join my (blog) voice to his and Liz's and suggest to the community: let's start writing User Stories with the following format:

• In order to <value to achieve>
• as a <customer role>
• I want <some functionality>

What do you think?

Story points explained, a good addition to the timeboxed estimation pattern

Just after writing the post about about Never ending design discussions I found one post from Lasse about story points. I think these two posts go very well together, as story point-based estimations is what I use for the Timeboxed estimation pattern.