Monthly Archives: January 2012

Why user stories rule

Today I spent the entire day in a room full of people, going through 16 pages of user stories with a customer. A week ago they had never heard of user stories, let alone written one. They absolutely loved it. They understand what they want, we understand what they want, and we’ve now got an excellent set of requirements for the system they’ve hired us to build.

Having your customers tell you what they really want can be challenging, having them write a set of formal requirements can be impossible. In large part because writing requirements is difficult, and people basically don’t know how to do it.

Luckily, Mr. User Story is here to save the day. Many customers have no prior knowledge of user stories, so you need to sell the concept. You need to explain why user stories rule. They’re high level, they focus on functionality instead of technology, and they’re easy to read wether you’re an engineer or a paperboy.

Below is simple how-to, hopefully it can help your customer grasp the concept of user stories.

Roles

Begin by setting up a list of known roles that are in some way interacting with the system or product to be built. Examples could be “End user”, “Administrator”, “Sales manager”, “Economy” etc.

The user story – introduction

The actual requirement should be formulated as something we refer to as a “user story”. This is basically a sentence formulated in a particular way.  The point of this sentence (or story), is to ensure that the solution to the requirement will provide actual value to a known person or role. We need to understand who has a problem, what the problem is and why it is a problem.

As a <role> I want <goal / desire> so that <achieved value>

Confused? I’ll explain in a second – let’s just go through the document setup first.

Document setup

Segment the document, don’t just list 50 user stories in a row. Sort them by functionality, or possibly by which part of your company that will be using the result. How many stories and how detailed you make them is up to you. You should probably spend more time on the stories that are most important to you now, and then we can build on the rest later on. You’ll want to order the stories roughly by priority as well. This way you’ll spend most time on the most important requirements when discussing them with the supplier.

The user story – why and how

The goal of the story can be very specific, but it’s often better if it’s not. It may be best if the story doesn’t tell us HOW to solve the problem. Don’t worry about the solution, or ponder about technical challenges. We need to know what you want and how, let us figure out the best way to solve it. Focus on defining the problem and explaining what value is gained by fixing the problem.

Example #1: A circular story (not so good)

  • As a book store owner I want an SMS platform, so that I can send text messages

Example #2: A concrete story (better)

  • As a book store customer I would like to receive a text with a tracking number, so that I know when my books will arrive.

Example #3: A generic story (even better)

  • As a book store owner, I would like an effective way to communicate order information, so that I can reduce the time spent following up my customers.

The first story isn’t very helpful. Why do you want to send text messages? Who do you want to send them to? The second example defines a specific role with a specific problem, and clearly explains how this will add value. The third example also tells us what the goal is, but contains no specific information about how to solve it.

The second and third story are both okay, but may lead to different results. The second example will probably lead to a solution using text messaging to communicate, and it may be limited when it comes to what kind of information we can send to the customer. The third example doesn’t limit the communication form to text messaging, and is also more high level about what kind of information we can send.

Also note that the defined role is different in example #2 and #3. It’s basically the same goal, but example #3 focus on the role that has most to gain from the story. It’s great that each individual customer can receive a text message, but it’s even better that the book store owner can reduce the amount of manual work involved in her business. Example #3 does a better job of explaining how we can reduce cost and increase value.

So, is example #3 perfect? Not without more detail:

Additional stories and requirements

To help detail a user story, you may need to add additional stories and / or acceptance criterias below the first one. The main problem is to understand when to stop. For larger projects, the number of stories can become unmanagable. Stop as soon as all parties have a broad understanding of the problem at hand, and all high level requirements have been addressed. If you are lucky enough to have a customer that accepts an iterative process, you may proceed with mockups and prototypes to get the final details right.

Congratulations, there is now a reasonable chance that the result of your effort will match the expectations!

@TSigberg

Advertisements

I click and I click but nothing happens!

I’ve been surfing the web since it arrived in the 90s. So why do I still click several times on the mouse when a page fails to load within a few seconds? I know very well that with each click I’m sending another request to the web server. I’m basically stabbing it to death with my mouse. 

So why? Because I’m freakin’ frustrated, that’s why. I grew up with MTV, if nothing happens within 3 seconds I get so bored I  throw a fit or fall asleep. The average user sense a delay if it takes more than one second for something to happen after they click their beloved mouse.

So what does that mean in my world? It means that when developing a new web based service, focus on speed is vital. I don’t care how many great features you cram into the product, If it doesn’t look good and load fast you’ve still got a problem. Below are some basic guidelines when developing your new website.

  • Surfing your service (loading the login page, logging in and clicking on the available menu items) should on average take less than one second per click, and never more than two seconds.
  • Any action that takes more than three seconds on average need some kind of visual notification. Put in a a load bar or a blinking “Please wait” to make sure the user doesn’t forget that he actually did click when he wakes up again.
  • Nothing (including reports) should take more than 10 seconds to load. Ever. That’s an eternity. Most people on Facebook was born less than ten seconds ago. If your report takes more than ten seconds, pre-fetch it and store it in cache or on disk. Or you can send it to the user async via email, so that you can respond to the user immediately with “Your report will be delivered to your email shortly”.

But what about the internet itself, you ask. My server is super fast, but my site still loads slow for some customers! A study showed that on average it takes 6 seconds for a page to fully load. Only 0.6 of that time was server processing. 1.4 seconds was the actual network traffic, and 4 seconds was processing on the client computer.

So we can blame the user and his crappy computer, then? I knew it! It’s always the users. The world would be better without them, I always say. That means you’re off the hook right?  Not quite. The amount of processing required on the client is based on how you build your web site, and how much client-side javascript and whatnot you cram into the page.

So your code should be lean, just as your development process. Hopefully your service is about improving a process that creates value for your customer. That means the faster your service is, the more value (and less frustrated) your customer will get.

So the next time your customer or product manager asks for an animated duck in the background of the new administration interface, make sure he knows that it will slow down the load time of each page with several seconds. When you ask “Does the duck add value?” and your product manager says “Yes”, you can kick him in the knee and tell it’s from me.

@RevioCTO

Personal Kanban

My first post will be about a recent discovery, personal kanban.  I’ve been managing software development based on KANBAN the past few years, but it never occurred to me that I could use the same concept for personal task management.

Personal kanban is basically about two things: Visualize your workflow, and limit work in progress.

Visualize your workflow
In a process based on KANBAN, you usually throw a board up on the nearest wall, draw a flow and put the tasks into the workflow using sticky notes. Personally I prefer a digital board, and I’m using Agilezen for this purpose (for our team we use greenhopper).

Personal Kanban in Agilezen

My personal kanban board in Agilezen

I’ve got several columns on my board, but just start with “Todo”, “In  Progress” and “Done” and work your way from there. You should also have some kind of backlog (possibly outside of the board) so you don’t end up with too much in your Todo column at any one time. For some good principles for managing future tasks and todo, check out Getting Things Done by David Allen (more about that in another post).

Limit work in progress
When you’ve set up a board and figured out what columns to put on it, you need to set a limit for how many items you will allow in the “In progress” column. All work you’ve started but not finished, occupies a part of your brain. When your brain has to focus on several tasks at once, the quality of your work decreases. I know you think you are an expert multitasker, but you’re not.

These days, most people multitask like squirrels on speed. You start one task, *pling* an incoming instant message distracts you, and when you’re done chatting you start something else. Before you know it, you’ve got two half finished emails, you’ve written four lines on a document because you need feedback from your boss (and he’s out of town on business), and forgot what you were supposed to be doing in the first place. Limit your “In progress” to three, and you’ll be amazed at how quickly it fills up.

When you learn to limit your work in progress, you’ll find that you’ll get more done. Instead of doing ten tasks at once, you will be doing one task at a time. Not only will you become more productive, increased focus will also increase the quality of your work. You’ll also have a great system to keep track of all the stuff you need to get done.

This was just a brief introduction to the concept, for more information I encourage you to google “personal kanban”, follow #pkflow on Twitter or buy the book. If you have any time / task management tips of your own, feel free to share them below!

@RevioCTO