Tag: #AppliedAgileAnalysis

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.

We Are Neo

We Are Neo

Recently I was talking with someone who is transitioning into Business Analysis. One of the things we talked about is “What other job do you know where you get paid to learn from experts.” Our endless curiosity is met by an endless supply of industries, sectors, changing demands, new technologies, and on and on.

There is another side to that. With that endless curiosity comes an endless demand for applying what we learn – and sometimes for what we have not yet learned. Even for seasoned Business Analyst, there are tools and techniques that we’ve heard of but have not personally used.

And that creates a situation where…

We Are Neo

Who told Neo he could stop bullets?
Who told Neo he could stop bullets?

For example, let’s say a client needs to start embracing Agile but is struggling with a history of deciding everything before the project starts. As an Analyst, you may have worked on many Agile projects, and it’s second nature to you that some questions are not ready to be answered yet.

You do some research in the Agile Extension to the Babok Guide and discover a technique called “Real Options.” But you’ve not used this technique yourself.

What do you do?

You sit in the chair had have one of your Ebenezzer crew-mates plug you in to the “Real Options” program. A few minutes later, you know the pros, cons and concepts associated with using this technique.

Actually, that often is not as far off as it sounds. Oh, we don’t have a portal to plug into the Matrix. But we do have tons of articles, books, blogs and videos we can search.

The Choice Between Two Mindsets.

There’s a couple of ways you can look at what I just described. The first way is through the lens of “Imposter.” How can I claim to be something I’m not? They will see right through me.

The other way is through the lens of “Owner.” If I don’t do this, no one else can or will. Let’s try this and see if it works. If it doesn’t, we’re no worse off than we are now. And this stretches my wings as a leader for our organization.

To move forward we have a mindset that it doesn’t matter if I know it already or not. It’s my job to find the answers, not to have them already. So let’s go.

Consider this famous quote from Richard Branson:

If somebody offers you an amazing opportunity but you are not sure you can do it, say yes – then learn how to do it later!

— Richard Branson

There is a difference between this quote and what I’m describing. It isn’t always just presented to us. As Business Analysts, it is often presented BY us.