Wednesday, January 28, 2015

Features and User Stories

A key practice for successful Lean/Kanban teams is to capture business requirements well. Features and User Stories are a good way to do that. In this article, we'll discuss:

  1. What are Features and User Stories
  2. Structure of a Feature & User Story
  3. An example for a Feature and User Story. 

What is a Feature?

A feature is a unit of business value. It's what the Product Manager (i.e the business) wants you to build. A feature is a potentially releasable artifact. 

An example for a feature is:

Feature: User replaces word(s) in notepad
As a notepad user I want to replace occurrence(s) of a word in an open document with another so that I can make terminology changes efficiently

A feature should be expressed in ubiquitous language i.e. language of the business.

What is a User Story?

A User Story is a part of a feature. You could decompose a Feature into a few User Stories. By itself, a User Story is unlikely to deliver business value. However, User Stories can be developed and tested independently. User Stories address a key behavior in a feature.

An example for a User Story is:

User Story: User replaces a word in notepad one at a time
As a notepad user I want to replace occurrences of a word in an open document, one at a time so that I can exercise control over the changes I am making

It's important that User Stories address the behavior of the system rather than capture technical details. Always keep the User in mind, while writing User Stories. Just like features, User Stories should also be expressed in the language of the business

Structure of a Feature & User Story

They should have the following 3 sections:

     Title: Should be in one line describing the story. Example: User replaces word(s) in notepad

     Narrative: Should be expressed in a Role/Feature/Benefit format.
     Example: As a notepad user I want to replace occurrence(s) of a word in an open document with another so that I can make changes efficiently

     Acceptance Criteria: Acceptance Criteria provide a definition of "Done" and also help elaborate the story.

Example of a Feature and its User Stories

The example is that of introducing a feature called “Replace” to Notepad (let’s pretend the feature doesn't exist).

Feature: User replaces word(s) in notepad
As a notepad user I want to replace occurrence(s) of a word in an open document with another so that I can make changes efficiently

For example: I want to replace occurrences of “find” with “search”

Acceptance Criteria
  • I can specify and replace a word one at a time
  • I can replace all occurrences of the word with one button click
  • I can optionally make the replacement case-sensitive

User Story 1: User replaces a word in notepad one at a time
As a notepad user I want to replace occurrences of a word in an open document, one at a time so that I can exercise control over the changes I am making

Acceptance Criteria
  • When I click a button called "Replace" it navigates to the first occurrence of the from where my cursor is positioned, highlights it and replaces it with the replacement word
  • If I'm at the bottom of the document, the first word at the top of the document is replaced
  • If the word cannot be found, I get an error message like: Cannot find
User Story 2: User replaces multiple words simultaneously in notepad
As a notepad user I want to replace all occurrences of a word in an open document, simultaneously so I can be more efficient

Acceptance Criteria
  • When I click a button called "Replace All" it replaces all the words in the document
  • I get a count of the number of words replaced
  • If the word cannot be found, I get a message that says: Cannot find
User Story 3: User can make a case sensitive replacement
As a notepad user I should be able to make my replace case sensitive, so that I can make very specific changes.

Acceptance Criteria
  • When I click a check box that says "Match case" the replace is case sensitive
  • The default for the case sensitive check box is unchecked
  • If the word cannot be found, I get a message that says: Cannot find . In addition, if the "Match Case" is on, I need a warning that the search is case sensitive.

Wednesday, April 24, 2013

The Feed Forward Loop - A learning process

The Feed Forward loop is a process to become a “Learning Organization”. Successful teams and eventually successful businesses are those that learn the most in the least time.

I call it the “Feed Forward Loop” because it’s purpose is to fuel the next cycle. It’s a forward looking cycle that aims to deliver scientific learning in every loop. Every initiative that an agile team starts must be targeted towards increasing learning in the shortest possible time. For example, you should aim to learn more about the customer, the business, the market, etc. As you know, learning is best accomplished by doing. The Feed Forward Loop facilitates that.

There are four steps in the loop:

1. Hypothesize
State your assumption for the initiative that you are about to launch. What do you intend to achieve? What are your success/fail criteria?

2. Test
Devise a method to test the initiative. 

3. Measure
Measure the outcome of your test. Did it pass or fail? Did it validate your hypothesis?

4. Learn
This is the key to the initiative. Whether the initiative succeeds or fails, there’s always lessons to be learned. Use this learning to kick off the next cycle.

Monday, October 29, 2012

Kanban: Assets and Liabilities

The next time you look at a Kanban board, pretend to be an accountant. Look through the eyes of an accountant. You'll probably see two columns like most accountants do - Assets and Liabilities.

Don't see them? 

Work that is "Done" or "Released" is an Asset. Companies make money when work is done. You'll probably find this on the right side of the board.

Now look to the left. Those are your liabilities. All this work that's "In-Progress" - they are liabilities. You can be proud of them, but they are not making you money. In fact, it's quite the opposite - they are burning money.

So what do you do with this knowledge?

Start converting your liabilities into assets. Don't add new work (i.e. increase liabilities), instead create more assets (i.e. complete work). Work from the right side of the board.

Stop starting, Start Finishing.

Sunday, February 26, 2012

The Daily Kanban Stand-up

Many teams transition to Kanban from other agile processes. And often,  they conduct the daily stand up just like they used to in their previous process. Since Kanban is an evolutionary method, in the beginning that's fine. However, very soon you'll find that changes are necessary.

Teams new to Kanban use the stand up like a status meeting - often taking turns to update the team on the status of  their "tickets".  Or, they keep it very Scrum like, typically answering the following questions, with some variation,  in a round robin format:

  1.  What did I accomplish yesterday?
  2.  What can I commit to doing today?
  3.  What are the impediments in the way?

While that may have been appropriate for your past agile process, of the three questions, only the last one is relevant in a Kanban stand up.

(1) is unnecessary because the cards on the board tell the story. The WIP (Work in Progress) is visual.

(2) is irrelevant because work will take whatever time it will take to get done. Committing to accomplishing the work will not necessarily make it faster. Often, that leads to heroic effort. In addition, the focus on completing the work that has been "committed" to can actually come in the way of continuous improvement.

So,  what should we discuss in the stand up? I'd suggest:

  1. Impediments: What's impeding us?
  2. Flow: What's the flow like?
  3. Kaizen - or "Continuous Improvement": What can we improve?

Let's take a deeper dive into these questions.

What's impeding us?
Impediments are in the way of getting work done. Impeded work items should be marked visually on the board - usually with a pink sticky on top of it. Team leads or managers should focus on getting these impediments removed as quickly as possible.

Note that you don't have to talk about which item is impeded - that's obvious from the board. The conversation should be around resolution.

What's the flow like?
Kanban looks at software engineering as a flow problem.  The board will show where the bottlenecks are and therefore what's preventing the team from accomplishing more. The conversation should be around smoothening the flow and what actions the team can take to relieve the bottlenecks.

What can we improve?
Kanban is an evolutionary method. It's success largely relies on a mindset that's looking to constantly improve. These do not have to be big changes and can be a series of small improvements. Having a brief conversation on this topic everyday will make it clear that it is everyone's responsibility to make the process better.  When suggestions for improvement come from the team (rather than from managers), there is greater ownership and more likelihood of success.

These are the core questions. Here are some additional practices for a successful standup:

Ensure the board is up to date before the stand up
Many teams also use electronic tools along with a board. It is important to keep the two synchronized. Before kicking off the stand up, ask the team if the board is synchronized.

Celebrate the small victories
The done column on  the board should ideally have two parts. Work done for the week (or an appropriate time period) and work done since the last stand up. You can now see what got done since yesterday. Call attention to what got done. Recognize the effort, if only for a moment. Bring your hands together. Yes - applaud and cheer.

Celebrate small victories and energize the team.  And move on.

Change facilitators
Encourage different team members to take on this responsibility. When you facilitate, you'll get a different perspective of the process. You'll also take more ownership and funnily enough, suggest more improvements.

End the stand up on a high note
 If you have a team song, team dance, a war cry - do it. It'll always elicit a laugh and keep good cheer.

 I'd encourage you to try these practices and improve on them. You should bring in your variations to the stand up around the core practices.

Remember - the goal is to continuously improve.

Monday, November 21, 2011

Kanban Introduction

Kanban Blog

Saturday, September 17, 2011

WIP limits - The magic sauce in Kanban

A software development process can be viewed as a queuing system. Little’s law states:

Lead Time = Work In Progress / Throughput

Lead time is the time that a work item (represented by a card on a Kanban board)  spends in a system in various work states. We want to reduce that, so we can get more work done i.e. increase throughput. As you can tell from the equation, reducing WIP (work in progress) is one way of achieving that. 

Less is more

We've all heard that and have certainly experienced that. That's an earthy way of stating Little's law. We can get more done, when we are focused and working on fewer things.


We are not wired to work on multiple tasks at the same time. When we say we are multitasking, we are really switching our attention from one task to the other i.e switching contexts. Context switching is a waste. Studies have shown that with every additional task taken up there’s a 20% loss. If we are working on three different tasks, we’ve lost almost half the time in just context switching.

Grandma was right - less is more. But don't tell grandma that. Not unless you want her to limit you to just a couple of  freshly baked cookies instead of the usual half dozen. 

Ok, we should limit WIP.  But how do we determine the WIP limit?

We experiment.

If we set the limit too high, we will continue working on multiple tasks. If we set the limit too low, we may cause bottlenecks and affect the flow of work in the system.We want the WIP limit to be optimal so we can have a smooth flow.

But it’s not a science. The board will tell you. 

There are advantages to starting with a lower WIP limit

Yes, they’ll cause starvation and pain. But lower limits will expose potential problems in the system. The industry uses the analogy of the WIP limit with lowering the waterline. Lowering the waterline exposes the rocks (i.e. bottlenecks and constraints).  When the problems are exposed, the team can work to remove the bottlenecks and constraints until the work flows smoothly again. 

And so on and so forth.

It creates slack

When everybody is working  all the time, there's not much time to introspect, retrospect, experiment, innovate or even  have lunch. As a rule of thumb, lead times go up when utilization crosses around eighty percent.  High utilization is not good. We've probably experienced this when the highways begin to fill up with cars or when the CPU on the computer gets toward its capacity.

How do we create slack?

We could hire additional members on the team. Imagine going to the folks that handle the purse strings and telling them that we want ten developers in the team but we only want to keep eight developers working because we've heard that utilization  at above eighty percent is not good. Good luck with that :)

Or - we could apply WIP limits

If we have a team of ten and we've put an overall WIP limit of 8, and assuming only one person works on an item at a time, we've taken away work from a couple of developers. In other words, we've intentionally created slack (or  excess capacity). And slack is good because it will allow these two "idle" developers to do a few things such as pair up with other developers or help resolve issues at bottlenecks.

And funnily enough, this will help get more work done.

It's an enabler for a "Pull"system

A pull system is one where the downstream process pulls in work only when it's ready to process it. This will result in producing only what's needed, transferring work to a work station when needed and reduce inventories i.e. it will help result in a lean outcome.

When we have WIP limits, we cannot take on work unless  we have a "slot" available on the work station. We are consciously defining our capacity to take on work. Imagine if we did not have limits. Work would be "pushed" to us by the upstream process - whether we were ready or not. And  most likely, it would just wait  to be acted on. That's a waste.

WIP limits make Kanban a "Pull" system.

It's an enabler for Kaizen

It's not that we don't want to improve, but it's usually that we don't know where to start. Or what our bottlenecks/problems are. Lower work limits are a great enabler for continuous improvement (kaizen). When you run into the bottleneck, resist the temptation to immediately raise the WIP limit. Get a conversation started in the team and look to resolve the bottleneck. 

Pound the rocks to submission. And if you still have a bottleneck, raise the limit to enable flow.

Trust the board. The board does not lie.

Wednesday, April 13, 2011

BDD is not about tools

Many teams practicing BDD assume that the tool is the process. A lot of chatter is about: 
  • What BDD tool (or framework) should I use?
  • How should I use that tool?
  • Is tool X better than tool Y?
  • Etc., etc, etc. 
So much noise, that I’m afraid the intrinsic value of BDD is lost. Just because you are using a BDD tool, doesn’t mean you are practicing BDD. The tools are important, but not absolutely necessary. You could get a lot out of BDD without a tool. Here’s what I mean.

BDD helps build “Software that matters” 
In order to do that, you should capture requirements as behaviors resulting in a list of “behavior specifications”. In fact, that is what gathering software requirements is all about. You should define what the software should do (i.e. behavior) and frame it in the context of the business value.

But that’s hard.

Waterfall teams tend to write verbose documents, that developers find hard to understand. Agile teams err on the opposite side, writing terse user stories that often do not have enough information. BDD helps bridge the gap with the notion of User Stories that have two components: (a) Narrative and (b) Scenario.  The scenarios are the acceptance criteria and provide examples of how the software should behave. It helps to illustrate the narrative, providing a concise, yet vivid description of the expected business outcome.

You don’t need any new tools to do this.

It provides a language to document the behavior
The narrative is written in the format:

As A [role],
I want a [feature],
so that I [benefit])

The scenario is written in the format:

Given [context]
When [even]
Then [outcome]

This is a very structured way to express behavior.  “Given” describes the context or state of the system, “When” describes the user action or state transition and “Then” describes the outcome or expected behavior.  This expression almost feels like code. Yet it is in a natural language and more importantly, is in the language of the stakeholder. Because of the reduced ambiguity, you are likely to get what you are asking for. Especially, because you are also kind enough to tell the programmer/QA Analyst why a feature is required – a very important aspect of software requirements that is often ignored. Just adopt this format for your software requirements.

You don’t need any new tools to do this.

But it’s more important to discuss the behavior
Don’t just define behaviors, discuss them. Leverage the “Power of Three” i.e. the Business Analyst (a proxy for Customer or Product Owner), the QA Analyst and the Programmer in defining behavior. You can start with having the Business Analyst write the narrative and scenarios for the user story. But be sure to have the QA Analyst and the Programmer review the user story. Good QA people can elaborate the user story. Programmers can keep the specification realistic. Discuss it together, even if only for a brief time. These three stakeholders bring very different perspectives and expertise to the table. You’ll find that the scenarios get fortified with better acceptance-tests, including behaviors that were not originally considered. At the end of the conversation you will also have a definition of “done” for the user story.

You don’t need any new tools to do this.

It’s about baking quality in
Many defects occur because the requirements are ambiguous and subject to the programmer’s interpretation.  BDD fixes this through the scenarios with their rigid grammar. The scenarios provide the cues to the programmer to build the right features.  Defects also occur because the behaviors are not completely defined. This can be fixed by using the “Power of  Three” to inspect the user stories, discuss them and finalize them. This may take some time, but the investment will pay off. As the Toyota Production System says, “Inspection to find defects is waste. Inspection to prevent defects is essential”.

You don’t need any new tools to do this.

Engage the stakeholders
Leverage the “Power of Three” at every opportunity. Include the Business and QA analysts in the design and architecture conversations. Encourage the Programmer and the Business Analyst to review the test cases. When stakeholders, especially those that are more “outside” than “inside”, get involved in design conversations, they are more likely to drive a better understanding of the need and therefore influence the behavior.

You don’t need any new tools to do this.
However, you will need the BDD tools if…
You want to create “Executable Documentation” i.e. you want to record the behavior specifications in the BDD grammar in a BDD tool. Typically, these tools generate skeleton code, against which you write production code following TDD practices. Similar to the XUnit tools, initially tests will fail, and when the behavior is implemented correctly, the tests will pass.  This will provide traceability from the code to the business value.  More importantly, if you are disciplined, you will write just enough code to meet the behavior, thereby reducing waste.

In conclusion
A lot of the intrinsic value of BDD can be realized by:

-  Applying its User Story format
-  Documenting requirements using the recommended grammar
-  Leveraging the “Power of Three” to bake quality in the process
-  Engaging stakeholders to ratify and discover new behavior

And all of this can be done without BDD specific tools.

If you believe you are already following these best practices, then it's time to reach for the BDD tools. But not until then.