Wednesday, April 22, 2009

Concurrency: Integrating Business Analysis and User Experience into SCRUM Sprint Cycles

This blog article presents a model for concurrent Business Analysis (BA) and User Experience (UX) integrated with agile development iteration cycles.

How Business Analysis (BA) and User Experience (UX) can work more concurrently with development sprint cycles and maximize their contribution by eliminating wasted effort or unnecessary costs. This posting was stimulated by a Beyond Agile posting from David Castro who observed, “the BA groups and the User Experience (UX) groups really need to be working ahead of the current sprint.” While people in the discussion thread agreed with this statement, the concern was raised about how to integrate BA and UX activities into the agile development cycle and not fall into a “pipelined” development approach where detailed specification documents are created ahead of the time to sit on the shelf until needed.

This is my second posting in a series about how agile development can better leverage knowledge, expertise and practices of related disciplines. In the last installment “Tolerance” the concept of manufacturing tolerances was introduced to explain how UI / Web Designers can better guide development without “over specifying” details that either aren’t used or add unnecessary costs.

Just In Time Specifications:

BA and UX disciplines don’t claim that practitioners have all the answers, ready to give on a moments notice. They know how to solicit input from users and stakeholders and then resolve conflicts and priorities. The point is that this takes work and time that doesn’t always lead to instant answers when a developer has a question.

Ideally the homework needed to prepare for answering questions on a particular topic should happen “just in time” before it’s needed in a development sprint. This has two benefits: 1) knowledge is better used when fresh in people’s minds, 2) reduce inventory (of specs) that may not get used.

Success Factors:

  1. BA and UX work should be concurrent with development cycles (both release and iteration)
  2. BA & UX team members should work directly with developers
  3. The level of BA & UX detail should be just sufficient to start and feed the development work
  4. Finer details should elaborated as needed during (and sometimes following) the development iteration
  5. BA/UX work product should be tracked and evaluated in much the same way that velocity and stories completed are tracked for development sprints

BA & UX should work 3 concurrent areas for each sprint or development iteration:

1. Prepare for the next sprint – Create Specifications For Development

2. Actively contribute to the current sprint – Software Development Sprint

3. Use running software from the last sprint – Solicit Software Feedback

Here is a diagram showing these as 3 concurrent work cycles

This diagram is presented from the BA or UX view to show the work activities they would be involved with during any one sprint cycle. If your development team uses a two week sprint cycle, then BA and UX spend some of their time during each two week cycle preparing specifications for development in the next sprint cycle, some of their time working directly with developers on stories in the current software development sprint, plus some of their time gathering and filtering feedback from people running software created by the previous sprint cycle.

It’s useful to look at a simple value stream for this, in order to understand what you may want to track and measure for continuous improvement, What roles (disciplines) are involved, what is their work product (value added outputs), and who consumes or uses it (inputs). The following diagram remaps the concurrency diagram above to show a stylized value stream map with inputs and outputs. This map uses a sprint cycle symbol for processes in the map to emphasize that these are: 1) time boxed activities (cycle time = sprint cycle time); 2) performed concurrently with the prior (n-1) sprint, current (n) sprint, and following (n+1) sprint.

Agile Development Concurrent BA & UX Value Stream

Roles & Responsibilities

Adding business analysis and user experience to the agile development mix does add a level of specialization in addition to Product Owner and Scrum Master roles. Generic SCRUM would list BA and UX as part of the “Team” with "their bacon on the line." Much like a Product Owner, they have responsibilities to prepare ahead of each sprint, as well as participate in each sprint. One way to look at these roles is as an extension to the Product Owner role, which has a big job to do understanding and prioritizing the wants and needs of many different customers and stakeholders. This pattern has been applied successfully designating a “feature owner”, to whom the product owner delegates the breakdown from a release level feature into story level details and acceptance testing.

Product Owner Responsibilities

  • Product Backlog
  • Product Roadmap
  • Sprint Backlog

  • Next Sprint (n+1) Backlog or “wishlist”

BA and UX need to have visibility on what to prepare for at least one sprint ahead of time and this should come from the Product Owner. This is always subject to change. A good Product Roadmap can help in forecasting stories a sprint ahead.

Business Analysis Responsibilities

  • BA Domain Model - provides consistent concepts and terminology
  • Feature Specification (aka Story Outline)

User Experience Responsibilities

  • UX Design and Interaction Standards
  • Personas or Representative Customer Profiles
  • UI Storyboard (UI sketch “wireframe”)

BA and UX Specification detail should be just sufficient to start and feed the development work.

This article mixes agile development language with more traditional development language for BA and UX deliverables. While the deliverable names may be familiar the contents need to be adapted for agile development cycles.

It’s helpful to think of a Feature Specification as a story outline. BA should collect the information they need to tell a good story in the Feature Specification:

Who, What, Where, When, Why:

  • Who are the characters? Aka: use case actors, personas, customer profiles
  • What do they want to do?
  • What stuff do they deal with?
  • Where does the stuff come from?
  • When do things happen? Plot or scenario that ties the story together
  • Why do they care?
  • Why do we think this story will satisfy their wants and needs?

In a similar vein, user interface designers have borrowed the “storyboard” concept from the movies, using sketches or storyboards during the early stages of user interface design. The earlier “Tolerance” blog article talks about tradeoffs for UI “sketches” versus precise graphic layouts.

Finer details should elaborated as needed during (and sometimes following) the development iteration

In most cases, defer specific details for exactly “How” the software is going to work to the development cycle. Time boxed specification cycles act as a constraint to limit any tendency to create too much unused detail. Another way to think about using feature specs or UX designs is as study notes or presentation materials that BA and UX people refer to when talking with developers and testers, rather than static documents for bed-time reading.

Realize the Value of Running Software

Running software is a valuable tool for business analysis and user experience. It may be prototype, alpha, beta, or release. If people actually use it and experience it they will give feedback. Agile teams often don’t utilize the “potentially shippable software” from each sprint iteration. In many cases, it is like inventory sitting on the shelf until it all gets packaged into a release.

The “Solicit Software Feedback” process is one of the keys to successfully balancing the level of specification detail because it is the ultimate test of whether a story satisfies customer wants and needs. BA and UX become consumers of the running software delivered by developers and testers in this step. They are responsible for getting more immediate feedback into the agile development loop sooner. People in these disciplines have skills for usability testing and software validation. These practices encourage users to explore and experience a broader range of software functionality, sooner and to maximize the useful feedback gathered from them.

BA and UX are also responsible for collecting and classifying Issues and/or Defects versus New Features for the Backlog. There is some debate in the agile community about the value of differentiating between defects/bugs, issues and just another story. Many organizations separate these into maintenance and enhancement categories. In this case, there is value in distinguishing whether a story satisfied the desired capability for the target user or not. Is there a bug or issue that we missed in acceptance testing? Did we flat miss it, or now that we have running software did we see something new?

BA and UX Solicit Software Feedback Responsibilities:

Issues/ Defect

Problems discovered during user testing for immediate triage and possible insertion into the current sprint

New Feature / Enhancement

New features or stories that add capabilities or enhance usability in ways that weren’t anticipated or intended

User might say,

“Yes, I can and would use it as is, but it would be if…”


“Now that I can do X, I can see how I also want to do Y.”


A complete story rewrite is required to complete any level of functionality that is useful to a customer.

BA/UX work product should be tracked and evaluated in much the same way that velocity and stories completed are tracked for development sprints.

The best judges for the level of specification details are the specification consumers. In this case developers and testers are the consumers. BA and UX should let them guide what details are most useful in writing and testing the software.

Tune your process to achieve the best balance of just in time and just sufficient BA & UX detail. This will give you something controversial to talk about at Retrospective meetings.

Some questions to ask from developers and testers in the current development sprint:

· For each specification given as inputs to sprint stories, did someone actually use the specification?

· Was it clear and useful?

Did lack of detail or missing background information cause delay? Possible consequences:

· Developer had to wait a day or more to get answers.

· Story had to be deferred to a later sprint so that BA or UX could research needed information.


  1. I really like how this post elucidates the sometimes cloudy place where BA/UX people fit in the iteration cycle. This really jives with my experience as a BA in an Agile team, especially in describing the split focus of the past, present, and future, and how these responsiblities are balanced.

  2. Lots of clarity on a difficult area. This post certainly matches my experience.