I received the following question from a colleague a few days ago:

Name: Randy Raypole

Subject: User story design work

Message: With regards to team understanding of stories. I’m being told that the team gets a business need or story. They size it and then during the sprint is the time the design a solution for implementing the story. Seems the conversation needs to happen sooner. How can you size it without some idea of WHAT the solution will be? Is that correct?

Here’s my reply…

Randy, I think the answer is “it depends”. Or it depends on the design choices at-hand. What you’re hearing is the common (and relatively healthy) reply from an agile team that design “emerges” during the sprint. This is the essence of emergent design that you hear so many agilists talking about. It’s doing the design in a just-in-time, just-enough fashion.

I think for certain classes of user stories; this makes perfect sense. Stories that are well understood, straight-forward, build on previous stories, etc. In these cases, doing a whole lot of design pre-sprint execution would be wasteful. So don’t.

But in my experience, not all stories fall into this category. Perhaps 50% of product backlogs are stories that are straight-forward.

More Complex Stories

From my perspective, the other side of this reply is for complex stories. These stories warrant some early design thinking, as Randy alludes to. Here are some examples that quickly come to mind:

• Stories that will drive new extensions to existing designs;
• Stories that contain UX design elements;
• Stories that have a variety of design “options” to consider;
• Stories that we’ve not implemented before, where we don’t have a clue about the design approach;
• Stories where we need to experiment a bit to learn something. For example, the nuance of a set of API calls with respect to error handling and fault tolerance.

It’s these sorts of user stories that you don’t want to let into a sprint without some design thinking and pre-work. Now that pre-work can take a couple of forms:

• You could do some early design as part of a Sprint #0 activity. I know, I know, that’s not part of “Scrum”, but depending on the amount of design you have to do, it might be a prudent call.
• You can do it as part of a User Story – Research Spike. Usually this is for something more narrow, like deciding on a specific design direction.
• You could do it as part of the Backlog Refinement “process”, in that you can have design discussions in your refinement meeting(s).
• And you could have another group do it, as in an Architecture group or UX group who is working ahead of other teams and delivers some design work ahead of upcoming sprints.

Look Ahead

All of the above design pre-work I often call architectural look-ahead. SAFe calls it architectural runway. In that some members of the team need to be looking ahead, considering and tidying up design approaches prior to sprint execution.

You don’t want to look too far ahead, but you don’t want to allow these stories to land in a sprint without any look-ahead whatsoever. So there is a balance to be struck within each organization and project.

Wrapping up

I hope this helped Randy. I know he was looking for a precise, 100% of the time answer. And I clearly didn’t provide that. But I hope this made sense. It depends on the type of project, backlog, and stream of stories as to how you handle design.

The largest part of this decision-making burden falls to your team. You need to trust them to balance effectively. That is, to design ahead when necessary and to allow emergent design when possible. If you feel they’re “out of balance”, bring it up in the retrospective and see how the team reacts to that notion.

Stay agile my friends,

Bob.