Category: BA Techniques

Techniques: Job Stories

So, you’ve heard of User Stories. They represent requirements from the perspective of a User. But that’s not the only kind of requirement there is.

The distinction between a Job Story and a User Story is the perspective from which the story is told. Primarily, Job Stories focuses on the situation or scenario in which an action will be triggered. This shift can give additional information that might be missed in the more traditional User Story format.


The format for Job Stories is basically this:
When (a situation), I want to (motivation) so that (expected outcome).

Where User Stories focus on Who, Job Stories focus on When. Also, where User Stories state what is needed, such as a dashboard or report, Job Stories focus on actions to be performed.

It’s not that Job Stories are Superior to User Stories. But there are situations where to capture the intent of the work, you need to express it as a verb instead of a noun – or an action instead of an object. 

That distinction is where Job Stories are valuable.


Here are a couple of examples of Job Stories:

When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so I can go out to dinner with my friends.

When someone wishes to withdraw money from his/her account, the customer wants to know if funds are available, the teller wants to know if the person banks with us, so that the person requesting can received the desired cash amount.


Agile Extension to the BABOK®  Guide – section 7.4

As mentioned in the previous slide, the format is When (Situation), I want to (motivation) so I can (expected outcomes).

The Situation gives the trigger – when will this job happen?

The motivation identifies who needs to do what.  And it can involve multiple personas or actors.

The expected outcome can also be multiple.  On the previous example, expected outcome could be the customer receives cash and the teller reduces cash amount from the account.


Agile Extension to the BABOK®  Guide – section 7.4

One of the benefits of Job Stories is how this technique relates the Customer’s motivation. It can help to Think as a Customer, and build empathy.

One of the things that has struck me while studying the literature surrounding various Agile frameworks is the use of terms like Empathy in explaining the purpose of various techniques. One of the major elements required to pass the AAC exam is the Agile Mindset.  So understanding the empathetic side of the analysis is very important. Requirements are for people, and they need to reflect the motivations of the customer. Empathy is a requirement of the Agile Mindset in order to “Think as a Customer.”

The context for this is Requirements Management and the audience is the Internal Team.

Usage Considerations

Agile Extension to the BABOK®  Guide – section 7.4

We’ve talked about the strengths, giving voice to motivations and focusing on tasks instead of objects.  Job stories are also great for cause and effect relationships, as well as capturing the intended User Experience.

We’ve not mentioned this, but you don’t have to use just one format for requirements.  You can use Job Stories and User Stories.  Or you could use Wireframes and Models, or other formats. 

However, switching things between multiple formats can cause some confusion.  And try to keep it brief.

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: 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.


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.


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.

Techniques: Planning Workshop

I’ve heard many people say that Agile is against planning. If you’ve read many of my articles, you’ve probably seen me say something like, “It’s not that planning doesn’t occur in Agile. It’s just done differently.” The question is how.

Instead of laying out every detail upfront and measuring against that plan, Agile plans in chunks as time goes along. And this article is going to talk about how that is done – in the Planning Workshop.

Whether you are using Scrum, DevOps, Lean, or some other flavor of Agile, the Planning Workshop is used to communicate what can be delivered in a time frame.

With a title like Planning Workshop, there might be a tendency to think this is a session for the client. Instead, the goal is to determine what to work on next.


There are 5 elements to the Planning Workshop.

  • Input to the Workshop is an Estimated and Ordered Backlog. 
  • The team velocity, based on previous experience and projected schedules.
  • The goal to be achieved. Often this is an outgrowth of the Ordered Backlog.
  • There is the process of selecting the items from the backlog.  This can include bug fixes, research (Spikes), or any Product Backlog Item.
  • Finally – task planning, where the team breaks down their work and makes individual assignments.

Some important things to note. Most people think of Planning Workshops in the Development Horizon. That’s Sprint Planning, not a Planning Workshop. The Workshops are for the Strategic or Initiative Horizons.

Leading up to the Planning Workshop, no matter which Horizon, the team has estimated the Features in the backlog. 

Also prior to the Planning Workshop, the client or their representative has reviewed the backlog. We know this because it is ordered. This is a session for the Strategy or Initiative teams to decide what can be done in their next cycle, and the results to be communicated with the client.


Planning Workshops are a critical piece to most Agile frameworks.  They are utilized to align initiatives with organizational goals at the strategy horizon or to decide prioritization and sequencing at the Initiative horizon.  Here is where we align features within releases.

Planning workshops determine the intended goal and dates needed, clarifying priorities and details about the features requested.  Once that is understood, the team discusses how to complete the work.

The context is Communications and the Audience is Internal Teams.

Usage Considerations

Some strengths of the Planning Workshop include:

  • Frequent communication
  • Can involve all stakeholders for guidance
  • Because it is focused on a small set of the overall project, it is easier to understand.

Limitations include:

  • The amount of time required to convey a proper understanding
  • How lack of understanding can affect results

Techniques: Kano Analysis

When looking to develop a marketable product, one of the first questions should be how to determine features that will distinguish the product from others. Kano Analysis is how those market movers are found. But more than that, it helps recognize which features are essential to gain customer satisfaction.

The point of Kano Analysis is to determine what will drive market demand in a product.  One thing that is interesting about Kano is that it isn’t a one time thing because the results shift over time.  Like most things in Agile, revisiting previous results can lead you to finding a shift in what drives vs what is expected vs what you should avoid.

Kano Analysis Graph

Here’s the grid for Kano Analysis.  On one axis is the Degree of Achievement.  The other is Customer Satisfaction.  So Kano measures things in 3 attributes:

Kano Attributes

  • Excitement – The more of this you do, the more excited customers get along an exponential curve.  These are the game changers
  • Performance – These are things that go along a linear curve.  People expect to see these attributes.
  • Threshold – These are things that don’t get people excited.  But if you don’t have them, they get disappointed.  Again, it is an exponential curve, but it flattens out as you Achieve it.  These are assumed without mention sometimes, and are absolutely necessary.

Additional Elements

There is a 4th characteristic called “Indifferent” Addressing these would be seen as wasteful.  They might be viewed as a negative – a downward arrow.  Kano doesn’t show these.

To determine which of these 3 dimensions a capability belongs involves a survey. On a 5 point scale 2 questions.  The Functional form question – how do you feel if this is present.  And the Dysfunctional form – How do you feel if it is not present.

The 5 point scale is shown ranging from “I like it that way” to “I dislike it that way.”

The answers are put on a “Kano Analysis Questions Grid” which I’ll show you in a minute.  And from there we can see what builds along the 4 characteristics we mentioned earlier.

Kano Analysis Grid

So if you’ve looked at a sample of several surveys, you will see a pattern on how the respondents like or dislike a feature.  For example, if most of the answers fit into Functional Expect and Dysfunctional Dislike – That would mean this feature is a T – Threshold.

If it is functional Like and dysfunctional Expect – that means they DON’T expect it (it is a dysfunctional expect), but they do Like it.  They’ve not seen this often, but they want it.  These are the big market movers.  If it is a Dysfunctional Neutral or Live With, these are still on the Excitement curve, but perhaps not as strongly.

You can see, this is a very powerful market analysis tool.


Here is the Kano Analysis description.  We’ve covered this pretty well but I want to highlight the Context and Audience.

This is in the Product Management or Refinement context because we will use this technique to determine what to include or exclude from the product, as well as what has the highest priority.

And since the surveys are from External Stakeholders, this can be a great communication tool to find out from them what is desired, and communicate what we are going to address first.

Usage Considerations

One thing to highlight is, this technique is not to be used in a vacuum.  There can be other factors that determine priority.

Another thing is today’s perceptions may shift over time as features become more commonly accepted.  So the phrase “strike while the iron is hot” may be applied to the findings of Kano, meaning act while you can get ahead of the competition.

Techniques: Product Roadmap

The Product Roadmap shows the direction of the product and how the product is intended to grow. It demonstrates alignment to needs and a plan to deliver over time. The Product Roadmap is built around the vision for a solution, it outlines how the vision will be achieved and is defines how to measure progress.


Elements of the Product Roadmap include:

  • The Defined Vision and Strategy – as an input
  • Another input are the Desired Outcomes
  • Maintenance of the roadmap is performed by the Product Management Team, which ensures it is current and remains aligned properly

  • The roadmap will focus on a collection of requirements or themes, or features.
  • And it deals on a high level of things expected to be valuable to the solution.


Above is a simplified example of a Product Roadmap. It shows parallel development of some capabilities, some that are spread across multiple quarters, and some that may be delayed due to a dependency. This example shows that all capabilities are projected to be completed by Q4.


Dealing so closely with vision, it’s no surprise Product Roadmap is used for the Strategy Horizon. It identifies each feature and positions them in columns related to projected timeframes. This makes it a good tool for projecting resource requirements. The context is Product Management or Refinement and the Audience is the internal Team.

Usage Considerations

Product Roadmaps provide a shared focus on what is needed and overall direction, including MVP discussions. It can be utilized for discussions on priorities or other options. Variations can be provided for a target audience.

However, if the vision is chaotic, this tool loses effectiveness. Also, there is a potential to view this as milestones instead of overall directional goals.

And if it’s too detailed, it can be hard to maintain, so keep things at a high level.



Technique: Portfolio Kanban

Portfolio Kanban identifies the status of each initiative, this can be a simple communication tool to give visibility across all initiatives, as well as to monitor and adjust resource allocations.  It is used to give visibility to the Process, Work In Progress, which helps in decision making and feedback on the strategy level.


The Portfolio Kanban will have columns for each step in the organization’s process from idea to completion. Each column has defined criteria for when the item can progress and has limits for entering the column or the work in progress.

The important thing is that each initiative is represented.

Additionally, there are regular meetings to discuss the Portfolio Kanban board and affected prioritization. Metrics are updated to help with prioritization. It is displayed in a place where everyone can see it.


This is a vital tool for the strategy level because it allows decision-makers to have a visual understanding of all initiatives in the organization.  The information displayed can illuminate any bottlenecks and allow for decisions to re-allocate resources.  Also, utilizing Kanban principles, the organization may determine it is beneficial to place constraints or limits in certain cases, which actually increases speed.

The context is Communication and the audience is the Internal Team.

Usage Considerations

Some of the strengths of Portfolio Kanban are that you can set up varieties of this at the Initiative and Delivery horizons., and it allows Portfolio Management to be optimized. It increases feedback and visibility into what is in progress and where the bottlenecks are.

Some limitations are that it is a bit one size fits all at the strategy level – so if there are different paths for some initiatives, this would not work well for them.

And it doesn’t explain why an initiative is in one place or phase for an extended period, just shows that it is.

Techniques: Minimal Viable Product

Because of the title, many people are confused about Minimal Viable Product.

This isn’t the same as just getting by.  For example, if a new internal project is underway, the organization was already “getting by” previously. But the new MVP project provides essential coverage to meet a need without expensive “gold plating.”  If funding ran out and MVP was achieved, you would have a working product in the market or for your internal client and would be doing much better than before.  Additional features may be developed beyond MVP, but those are done after the product is viable. So, just because MVP is achieved does not mean the project will stop, just that it could and still be usable.

That is an important threshold to cross in product development.


MVP is an important technique for Avoiding Waste.  When a potential capability or feature is added to the solution, one of the first things we should ask is whether this is necessary for a product to be viable.

And by viable, that means that it meets the minimum requirements for the early adopters of the solution.

Again, it isn’t that non MVP features will never get done.  Just that the MVP features will come first. In other words, it avoids waste by giving priority to what is necessary.


In defining the MVP, it is important to address the following.

First, identify who needs or wants this solution.  Then from that group, identify the early adopters.

Next, identify what needs to happen for the goal to be met and how you can verify that has been met.

Thirdly, as the solution goes along, actually measure the results to verify the intended need is being met by the minimum solution.

Finally, Define the requirements for each feature of the MVP solution.


One interesting thing about MVP is how this focuses on early adopters.  If you do not satisfy them, you do not have a product.

Another aspect is this is not a static state – MVP can change over time.  As new features are identified, it becomes important to understand whether these are to become part of the MVP or whether they should be delayed for later – risking their exclusion from the product if there is not enough value.

That determination is how waste is avoided with this technique.

The context is Product Management or Refinement and the Audience is both Internal Teams and External Stakeholders.

Strengths and Limitations

Some of the things to be aware of for MVP Using are how it can be used to avoid unneeded or unwanted robust features.

Also, it’s important to realize the amount of research required to identify what is important for early adopters, and that sometimes features may be a best guess.  And if the solution is simple, going through all this might be overkill.

Announcing – AAC Certification Course on Udemy

Announcing – AAC Certification Course on Udemy

Hello everyone,
If you’ve not seen my announcement on LinkedIn, I have been very busy developing a course called Preparing for the Agile Analysis Certification Exam. It has been published on the Udemy platform, so it is available to everyone. This is a self-paced version of the course I have taught to Business Analysts across the US in association with the Bluegrass chapter of IIBA.

This covers the entirety of the Agile Extension to the BABOK Guide with over 3-1/2 hours of videos and several quizzes. The quizzes are intended to help foster the “Agile Mindset” and help you grow in understanding of the concepts presented in the Agile Extension.

If you are interested in learning more about Agile, becoming certified as an Agile Analyst, are curious about whether there is a career path for Agile Analysts, or just need some ideas on how to improve your projects – this is a great course to cover everything.


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.