Archive for the ‘user stories’ category

Newer Entries »

Agile Software Development Processes: Defining User Stories and Cross Functional Teams

August 20th, 2010 by damonpoole
Share|

Over the past ten years, a number of Agile software development process “guidelines,” or best practices, have formed and are now becoming widely adopted.  Terms used to describe these best practices are sometimes new to developers, so I defined the practices that I believe provide the most value to a wide variety of development teams in order to create a highly functional, unified software development process.  I have by no means compiled a full list, but over the next few posts I will introduce you to some ideas that you may find worthy of further investigation.

Agile Software Development Process: User Stories

Consider the following requirement and sub-requirements.

  • 3 Simplified Purchasing
  • 3.1 Customer Identification
    • 3.1.1 A web “cookie” shall be used to uniquely identify visitors
    • 3.1.2 Each customer shall be associated with a cookie
    • 3.1.3 Cookies shall be stored in an RDBMS
  • 3.2 Sale presentation
    • 3.2.1 Each item for sale shall have a button marked “buy” next to the item
    • 3.2.2 Selecting the “buy” action shall trigger an order placement action
  • 3.3 Fulfillment
    • 3.3.1 By default, all orders shall use the on-file default shipping information
    • 3.3.2 If available, all orders will use the customer’s default payment method
    • 3.3.3 It shall be possible for the customer  to cancel any order for up to 4 hours after they place that order.

This set of requirements is for something called “simplified purchasing.”  Take a moment or two to consider how you would sum it up in a single plain-English sentence.

The requirements called “simplified purchasing” describe the user’s desire for “one-click purchasing.” In terms of a user story this would be phrased as “As a user I want one-click purchasing.” User stories are a description of what is needed from the user’s perspective. User stories help to separate business value from implementation and focus all parties on the desired outcome.

User stories are different than requirements. When using requirements, it is likely that the developer implementing the requirement will be presented with an implementation task or a design document and be constrained to implementing as specified or as designed. A user story removes invisible constraints by focusing on the outcome desired by the user. The developer doing the work will see the user story, will be able to better understand what the user needs, and will be able to participate in or even own the specification and design of that story. User stories provide engineers more freedom to utilize their creativity and ability to innovate without the risk of implementing something that the user doesn’t want.

A user story does not necessarily replace requirements documents or other documents. A common scenario is that the user story is the unifying high-level description for the work that needs to be done to make sure that everybody involved has a common understanding of the work, from customer to developer to tester to doc writer and back to the customer.

Agile Software Development Process: Cross Functional Teams

A cross functional team is a small group of people (7 + or – 2) that works together towards a common purpose, where time is primarily spent as part of the team, and, as a team, has all of the skills needed in order to be self-sufficient. These skill sets may include server side programmer, web designer, tester, technical writer, project manager, etc. The intended benefit is that you spend less time waiting for other groups and bringing part-time participants up to speed, you lose less time due to communication delays, and individuals spend less time multi-tasking between multiple projects.

Next best practices I will explore? Collocation and Unit Testing.

No comments »

Posted in AccuRev, Agile, Best Practices, cross-functional teams, Educational Webinars, Tips and Tricks, user stories

Tags:

Breaking Down User Stories

June 28th, 2010 by damonpoole
Share|

There’s a lot of excitement about getting to shorter iterations. But with a shorter iteration comes a higher degree of difficulty. One of the problems with shorter iterations is getting all of your user stories to fit into them. For many stories it is no problem, but then there are the stories that seem to only be doable in the time it would take to do two or three iterations. What can be done? Is it even possible to fit all stories into a short iteration?

Before we get too far, consider this. Prior to Agile, what was the incentive to break a large task down into smaller chunks? If you thought it might take 2 months, why not take two months? After all, the release isn’t for 6 months. So, prior to Agile, even if something could be broken down, there wasn’t really any reason to do so. As a result, we’ve had few reasons to build up our bag of tricks for breaking tasks down. Rest assured, there are many techniques for breaking big user stories down into smaller user stories and in this post I’ll show you one of those techniques.

Fitting User Stories into a Short Iteration

New Picture1 300x196 Breaking Down User Stories

The diagram above represents a story that has a certain amount of value. In order to get that value, we have a bunch of work to do. That work cuts across the front end, the middle layer and the back end. An obvious way to split up the work is to do it a layer at a time.

But a user story is only a user story if it provides value to the user. Splitting a story up into “As a user I want the backend for X,” “as a user I want the middle layer for X,” and “As a user I want all of the UI for X” does not provide value until all three stories are complete. Stories need to provide value on their own.

New Picture 11 300x176 Breaking Down User Stories

Instead of breaking a story up into layers, try splitting it up by value. In this diagram, the original story has been broken up into three separate stories, each of which holds value in and of themselves. As a result, each story requires less work to implement. This process can be repeated (if desired) until you can no longer derive stories that still provide user value. At that point, each story is already as small as you currently know how to make it.

A typical example of breaking down a user story is “As a user, I want a calculator function.” This might be for a mortgage application, where the user wants a handy calculator that they can use as part of the application process. One might be inclined to provide a full-function calculator right out of the box. But it may turn out that all the user really needs is to be able to cut and paste numbers out of mortgage forms, into the calculator, add them together or subtract them, and then paste them back into the form.

If you are concerned that the calculator won’t have enough functionality at release, consider that (at least in this contrived example) they can always do what they want another way. But for some subset of users, you will have provided just what they needed. Based on user feedback you can then provide the next level of functionality. In just two short releases you will have provided more of what the end users really need than if you had predicted usage and done just one larger release.

You don’t need to split stories indefinitely, you only need to split them until they fit into your desired iteration length. As you split more and more stories, you will find that it gets easier and easier, and you will start to think in terms of smaller units of deliverable user value.

No comments »

Posted in AccuRev, Agile, Best Practices, Tips and Tricks, user stories

Tags:

Change Packages for Agile Workflow

June 24th, 2010 by damonpoole
Share|

User Story Based Engineering

In other blog posts I’ve talked about using Multi-stage Continuous Integration to scale Continuous Integration for use in multi-team environments and using streams or branches to model your workflow directly in your SCM tool. While both of these approaches work well and provide a lot of value, they can also present a new challenge: how to associate enhancement requests and defects, which can be lumped together using the term “work items,” with the changes that implement them?

If you are doing mainline development, life is pretty simple. On check-in enter the enhancement request ID or defect ID in the comments. Once that association is made, it is fairly straightforward to figure out which enhancements and defects have been checked in. On the other hand, the more people you have checking in to the same branch, the less likely it is to be stable, even if you are doing Continuous Integration. So, how can we maximize the benefits of using streams to represent process and integration stages and still have the ability to match work items to the work done to implement them?

Representing Process and Integration Stages with Change Packages

(Let me first point out that while I’m using the generic term “work item” here, in an Agile team one would most likely use the term “User Story.” Both apply equally well in this context, but I’ll stick with work item for now.)

There is an SCM concept that maps to a work item which can be tracked from place to place, and that is a “change package.” It is called a change package because it represents something which, once defined, can be applied to multiple places and tracked regardless of how many different places it has been propagated.

Change packages can be promoted individually or in groups from stream to stream. That way, as work is promoted from stream to stream you have a record of the content of each stream from a high level perspective instead of a files perspective. A list of files is not very meaningful or useful. On the other hand, change packages allow you to ask questions like “which user stories are in the stream that represents all user stories that are ‘done’,” without having to resort to mainline development.

No comments »

Posted in AccuRev, Agile, Best Practices, change packages, continuous integration, user stories

Tags: