Tag: #Agile

Techniques: User Stories

Techniques: User Stories

In this post, we will talk about one of the standard features of many Agile frameworks, the User Story.

User stories are a simple tool to breakdown components and features into small chunks that are understandable, estimable and convey the customer’s requirements to delivery.


Agile Extension to the BABOK®  Guide – section 7.21

Commonly, user stories are represented by a card, with a title representing the activity to be delivered.  This could be a physical card or electronic in some requirements management system such as Version1, Jira, TFS or others.

The format of the User Story identifies who needs this, what is needed and why.

They are a tool for elicitation in that the card does not identify everything there is to know, so this helps engage collaboration among the team. The idea is to describe the desired result, not how it is achieved.

There is acceptance criteria defined for the work produced for each card.  This criteria will have been approved by a representative of the stakeholder or a product owner, and is used to measure results to confirm the work.

User stories are used in conjunction with other techniques we have already discussed, such as those shown above under “User Story Management.” So that shows how central this technique is to agile frameworks.

INVEST Criteria for User Story Readiness

Agile Extension to the BABOK®  Guide – section 7.21

I won’t go into how to write a User Story.  For a discussion on that, there are numerous books.  I’d recommend User Stories Applied: For Agile Software Development by Mike Cohn.  But the Extension does give some guidelines on when a story is ready to be worked.

First, it should Independent or stand alone.  Primarily this goes back to delivering a product that works, and doesn’t need something else.  But I would add there’s a quality of uniqueness to this.  We’re not duplicating work.

Next, it is Negotiable.  The team can determine which is the best way to deliver it.  In other words, the requirement can’t say “Use this product”  We are not designing the product.  We are presenting the requirements, not determining how the requirements are met.  The team does that.

Next is Value.  In week 3 on Value Stream Maps, we talked about how some things do not add value to a process but are necessary.  Sometimes those are regulatory requirements.  Sometimes they are things like a cooling off period.  Although it might not drive profits, there is value in abiding to the regulations.  So, sometimes value needs to be expanded.

Can the team Estimate this.  Do they have enough experience for a frame of reference for their estimation?

Is it Sized Appropriately so that the the team complete this in a cycle.  If not, perhaps it should be broken down more.

Finally, the story should be Testable. There should be enough information to verify that the delivered product works.


Agile Extension to the BABOK®  Guide – section 7.21

Some things to remember about User Stories. These are intended to be the voice of the customer, so the intended results should be easily understood by the customer.

User Stories are one of several varieties of Product Backlog Items, though the others are not as commonly used.

Be sure to review the stories with the customer or their representative to gain approval before beginning work.

Also, remember this is a collaboration tool to ensure that

Usage Considerations

Agile Extension to the BABOK®  Guide – section 7.21

The considerations for User Stories are that they are small, implementable and testable pieces of work.  They are useful in gathering feedback both prior to delivery as well as during demos.

However, they don’t have all the answers, and if you’re not careful, can inflate the backlog.

Also, they tend to be oriented toward what and sometimes misses the why of an item.

Techniques: Visioning

Techniques: Visioning

Visioning is used to determine the desired outcome for an initiative worded in a concise and approachable manner.

Agile Extension to the BABOK®  Guide – section 7.24

When Patriots coach Bill Belichek meets with his team to begin practices, I would imagine that the first thing he says is something like “Our goal for this season is to win the Super Bowl.”

Everything else the team does is derived from that goal.  The team may not fully know how they are going to do that.  And certainly the other teams want to prevent them.  But everyone on the team knows that when Coach says “We’re going to win the Super Bowl” he knows they can succeed. And they understand what winning means.

Elements of Visioning

Agile Extension to the BABOK®  Guide – section 7.24

But there’s more to Visioning than simple inspiration.  Yes, it is a set of beliefs.  But it also is a SHARED set of beliefs.  Everyone gets there or no one does. That is called a Vision Statement

This shared set of beliefs comes out of facilitated vision exercises – or Vision Exercises. Finally it is expressed in detailed objectives to measure the goals – known as Impact Metrics.  These metrics show that the plan is working, but are not necessarily cause and effect related.

Back to Football, Coach may set goals for player’s strength, speed and skill.  Will those cause them to win?  No. Will they help? Yes. That’s the difference between correlation and causation.

Visioning Description

Agile Extension to the BABOK®  Guide – section 7.24

Visioning begins in the Strategy Horizon, where the organization determines which initiatives align to organizational goals. The vision for an initiative is set just before the beginning of the project and lasts through it’s duration.

The Vision Statement helps orient all those involved in the project toward the overall goal both of the initiative and the organization. It identifies how the resulting product will leave an identifiable mark on the products or services provided or on the organization as a whole.

One additional consideration is that Visioning may be associated with multiple related initiatives.

Finally the context is communication, and the audience is internal teams and external stakeholders.