I have run into the same questions on nearly every coaching engagement where there was a team that included Business Analysts (BA) and User Experience (UX) designers:

  • How do we work with BA and UX specialists on an agile team?
  • How do we avoid being ‘waterfall’ when we feel we need to do a lot of upfront work to prepare stories for development?
  • If we have BA and UX specialists working-ahead of the development team, how do we track the work of the UX/BA resources during an agile project?

I like to explain this in the context of a larger product team – with the expectation that all the specialists will self-organize to accomplish the goal of the project.  At a high level, I think this works – but when it gets down to who is doing what, when, and how we manage and track that work, it helps to be a little more specific.  I’ll start the discussion with my view of the “big picture” and then discuss what I have seen work in the past.

Think holistically, Work incrementally

When it comes to user experience and technical architecture, I like to repeat the mantra: “Think Holistically, Work Incrementally” as a fundamental way of thinking in an agile framework.  It’s o.k. to think about the user experience and technical architecture — and even do some design up front.  As long as you plan on executing incrementally, being flexible, learning as you go, and responding to change.

I have run across many people who believe that thinking ahead about architecture and user experience design is somehow “un agile”.  I am not sure where this comes from, but I think it’s based – at least in part – one of the 12 agile principles associated with the agile manifesto:

“The best architectures, requirements, and designs emerge from self-organizing teams.”

I agree that this principle is sound, and that emerging architectures and designs are a good thing.  However, I have found it has been both reasonable and beneficial to so some up front thinking and design of the technical architecture and the user experience design.  It helps to have a map to follow when we start working incrementally.  In fact, I have found one of the best ways to determine which stories are needed to build a product come directly from some of the UX work that is done up front.

I hope that it’s not too difficult to see the distinction between thinking holistically, and thinking ahead and a waterfall approach to development.

So, UX designers – feel free to think big, work through the process of persona development, information architecture, site mapping, wireframe development, rapid prototyping, collect data with user studies, create wireframes, and sketch out the visual design.  There is nothing unreasonable about looking the big picture up front.  But, and this is key, we don’t want to have finalized UX designs and fully formed and documented stories (in the format of detailed requirements) that are “handed-off” to developers without the expectation of detailed conversations and close collaboration in each and every sprint.  We must focus on working incrementally – building out slices of the full featured application in small (2-week) iterations.

Getting Specific

Now, moving from the “big picture” philosophy and focusing on actually answering the common questions:

  • How do we work with BA and UX specialists on an agile team?
  • How do we avoid being ‘waterfall’ when we feel we need to do a lot of upfront work to prepare stories for development?
  • If we have BA and UX specialists working-ahead of the development team, how do we track the work of the UX/BA resources during an agile project?

Two teams?

One approach that I have seen work pretty well is to have two teams:  A “Product Owner Team” and a “Development Team”.  Both these teams are considered part of the same product / project team – but their work is managed and tracked differently.  (See Figure 1 Below)

The Product Owner (or product owner team) is responsible for defining and prioritizing the features in a backlog, typically by writing many, many, stories that are used as tokens that represent the features and capabilities that we need to build.

ProductOwnerRoles

Figure 1 Team Concepts and Mobile Resources

The most effective product owner teams that I have worked with consist of the Product Owner – that individual who has final accountability for the product, Agile Business Analysts (BA) – those individuals who help discover, understand, and capture all the details such as business rules, workflow, and the UX designers – those individuals that come up with and validate the big-picture design of the product from a user interface and interaction perspective.  These specialists work together to build out the initial product backlog and participate in the “grooming” of the backlog throughout the project.

The development team is basically, all the people who do the work of building the product within the sprints.  This includes, as you would expect, developers and testers – but it also includes those same Agile Business Analysts (BA) and User Experience (UX) specialties that are part of the product owner team.  These specialists are flexible and mobile, working with different focus depending on what they are working on and when!

Specialists are flexible and mobile

One of the core principles of agile is the cross-functional, self-organizing team.  In my view, this includes all special skill sets on the product / project team – including Business Analysts (BA), User Experience Designers (UX), Subject Matter Experts (SME), Developers (Dev), and Testers (QA).  Even the product owner and scrum master / project manager – who are often considered separate rolls from the team – are part of the overall project team.

As shown in Figure 1, the BA and UX specialties work both as part of the product owner team – working a sprint or two ahead of the development team to build out the backlog – that is, fill the hopper of work that is ready for planning in a future iterations, collect details about business rules, capture details about user experience design and conduct usability studies, etc. These specialties also work as part of the development team – working on tasks within the sprint along with the developers and the testers (aka the team).

The distinction on which “team” the BAs and UX Designers are working on is determined by what they are working on, and when they are working on it.  These specialties both work with the team in the iteration and work ahead of the development team (often with the assistance of developers) to help prepare the work for future sprints.

 Managing and Tracking the work

The next challenge is how to plan and track the work when we have two teams working on the product and some of the people (BAs and UX Designers) moving between the product owner team and the development team throughout the project.

I like to track all the teams work – whichever team – using a visual Kanban style task board.  I have found that having the development team work in a traditional (Scrum Style) time boxed iteration of two weeks works best – for the development team. In this case the BA and UX work that occurs as a specific task that must be completed by the development team – including BA and UX specialties – is handled the same way as before: specific tasks are added to the story board, estimated in hours, and tracked through the workflow (TO DO, IN PROGRESS, DONE) just like any other task.  The only difference is which team member is most likely to do the work.

I have tried to use the time- boxed approach with the product owner team – but didn’t have much luck getting that to work smoothly.  This was primarily due to the fact that to detailing the stories and coming up with high-level UX design often didn’t fit well into an iteration for various reasons and the standard scrum approach became awkward.

Having little success with the time boxed approached; I switched to a true Kanban approach to manage the Product Owner team’s work.  Using the visual tracking and explicit work in progress (WIP) limits.  This seemed to allow the flexibility needed, and keep the team focused on fleshing out the details of stories that were likely to come up in the next iteration or two. This worked much better and supported the needs of the product owner team without the awkwardness of the forced time box. (Note this worked largely because our need for predictability and velocity measurement was not important for the work the PO team was doing.)

Conclusion

As you can see, the BA and UX specifies are very important in both defining the features and capabilities of the product when building and detailing the backlog, and in completing the stories within in an iteration.

By focusing on working incrementally and making sure that we don’t use detailed or documented stories and UX designs and wireframes as a means to avoid conversation and hand-off work from one specialty to the next we are still working in a reasonable and responsive “agile” approach.  It’s the hand off that makes the waterfall not the fact that some thinking and design is done outside an iteration.

When we have two teams working at the same time, but often on different stories and tasks, it important to tack the work of both teams.  I recommend using the scrum time boxed approach for the development team, making sure that all work fits within the iteration where BA and UX specialists add and work on tasks using the same approach as the development team.  I recommend that the Product Owner team use a true Kanban approach making sure to visual the work using a task board and enforce strict work in progress (WIP) limits to ensure that stories are taking through to completion.

The approach described above has worked on several projects that I have worked on.  But, as always, your mileage may vary.