Tag: #BusinessAnalysis

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.

Elements

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.

Description

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: Real Options

Techniques: Real Options

Real Options focuses decision makers attention on the items that need to be decided now, at the last responsible moment.  By focusing on the appropriate time for making a decision, items which are not needed can be delayed making the decision process much simpler.

Think of it this way, to be agile, we need to have flexibility.  However, the criticism is that with flexibility comes chaos. How can we bring in the latest information and use it for decisions in an orderly way – without disrupting everything we’ve been planning? We need a way to make a decision based on a logical framework, and Real Options is one of the techniques that has been developed to do just that.

It starts with the question, “What is the latest point at which a decision can be made?”  Anything before that means we may have missed important late breaking information.  Anything after that, and the decision is made for us.

In other words, there is a valid reason for Procrastination.

Elements

Agile Extension to the BABOK®  Guide – section 7.12

It’s a little different from how we normally think about problems and decisions.

First, An option is only an option if it can expire.  Otherwise there’s never a reason to decide.  So by definition, options have a point where they can expire.  That can be a point in time, or an event that triggers a decision point.  So long as it can expire.

Next, if this option is taken, one or more other options are excluded.  This is a choice of one out of more than one, with one choice winning.  If a competing option is still available after the choice, then it was not paired with the right option.  In other words, it wasn’t understood correctly.

If there’s a “cannot” phrase associated with the option, then it isn’t an option either.  Options are only options if they can be put in place.  If there’s a reason it cannot, then it isn’t an option.

That sounds intuitively true when you think about it.  But we don’t usually think about it that rigorously.

In addition, options must exist within organizational commitments, such as standard tools, acceptance criteria and delivery.

As mentioned, they must have a means or time when they expire, after which the choice is made for you instead of by you.

The earliest option defines the end date for the collection of information in order to maximize the ability to make a decision.

Description

Agile Extension to the BABOK®  Guide – section 7.12

There are 3 statements that are important to remember, highlighted in the Process section here.

  • Options have value
  • Options Expire
  • Never commit early unless you know why And this belongs to the Product Management or Refinement context, directed toward the Internal Team.

Usage Considerations

Agile Extension to the BABOK®  Guide – section 7.12

As we stated at the beginning, Real Options simplifies decision making by allowing the decision-maker to focus on decisions that are needed now, instead of the entire project upfront.  This removes complexity and allows decisions to be prioritized based on events, time, or other constraints.

But it isn’t the most intuitive way to think about decisions, which means – though it simplifies the decision itself, the process supporting this technique is not so simple.