Monday, February 27, 2006

User Stories and What they are in "Simple terms"

A Very good explanation from the Mayford technology website :

A User Story is a short description of the behavior of the system from the point of view of the Customer. They are in the format of about three sentences of text written in the Customer’s terminology without technical jargon. In simplistic terms, user stories are the response to, "Tell me the stories of what the system will do. Write down the name of the story and a paragraph or two."

The conversation takes place during Iteration Planning, at which time the Programmers ask questions of the Customer in order to flesh out the details of the Story, and then brainstorm the Tasks required to implement it.

Typically, the stories are written on 3" x 5" index cards, although an electronic copy may be used. Since index cards are somewhat small, they automatically limit the amount of writing that can be put on them (which is a good thing). This forces the Customer to focus on making the text clear and concise, while being as simple as possible.

Story cards are a great conceptual tool. When they are laid out on a table, the Customer can visualize the entire system. Since the cards can be easily moved around, the Customer can 'see' the system from different perspectives. They also work well during development, providing a very concrete reference to how much has been completed, and how much work is left.

Once the Stories have been estimated and the initial Project Velocity set, the Customer can make tradeoffs about what to do early and what to do late and how various proposed releases relate to concrete dates.

There has to be at least one story for each major feature in the system, and it must always be written by the users. The programmers shouldn't write the stories, but they have conversations with the users that are then attached to the stories together with pointers to supporting documentation.

Different than Requirements

A typical misunderstanding with user stories is how they differ from traditional requirements specifications. The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the Customer and receive a detailed description of the requirements face to face.

Another difference between stories and a requirements document is a focus on user needs. Details of specific technology, data base layout, and algorithms should be avoided. Stories should be focused on user needs and benefits as opposed to specifying GUI layouts.

How z user story different from use Cases ?

One approach that has been suggested is to define the Stories during the Planning Process, and then create a Use Case for each Story at the beginning of an Iteration. This allows the deferral of specifying the details of a Story until they're really needed. Some would argue that Use Cases aren't really needed, although it may be a requirement for your organization. At any rate, Stories and Use Cases aren't mutually exclusive.

Friday, February 24, 2006

Lean Manufacturing and Software

A Nice article on lean Software Development:

Lean Manufacturing and Software: "Value and Waste

A good starting point is to consider what value is, and what waste is.

What are things with value?

* Raw materials
* An end product that someone is willing to buy
* Tools used by the team
* The skills acquired by the team

What about intermediate products? They have some value in the sense that they give us the option to create the final product more cheaply than if we started from the beginning. They have no value if nobody is willing to buy the end result. And intermediate products clearly have a cost.

And what is waste?
If it doesn't add value, it's waste.
--Henry Ford

Waste – anything other than the minimum amount of equipment, materials, parts, space, and worker's time, which are absolutely essential to add value to the product.
--Fuji Cho, chief engineer at Toyota

Taiichi Ohno is known as the father of lean manufacturing, and he identified seven types of waste. We'll consider them and find an example of each applied to software:


Software Example


Features that nobody ever uses.

Waiting Time

QA waiting for a feature to be written so they can test it.

Transportation Waste

Time waiting for files to copy.

Processing Waste

Software written that doesn't contribute to the final product.

Inventory Waste

A feature for which development has started, but nobody is currently working on it.

Wasted Motion

Doing a refactoring manually when the development environment can do it automatically.

Waste from Product Defects


Ohno talked about a diagram of a boat that represents the pipeline translating raw materials to a finished product, traveling across the sea of inventory. Every waste in the system is like a hidden rock at the bottom of this sea, which may be a hazard to travel over, and which raises the level of the water and makes the boat travel further.

To make these rocks visibl"