Here at Herrmann, our team members are big believers in Agile software development philosophy, particularly the Scrum variety. We've been using Scrum since I started here almost five years ago, and in that time we've been able to expand on the baseline Scrum processes and add a Whole Brain® Thinking spin to them. The place where Whole Brain® Thinking has made the biggest impact has been how we write our user stories.
If you're also an Agile team, you're probably familiar with the notion of user stories. Surprisingly enough, if you're using user stories in your workflow, you've already started down the path to Whole Brain® software development.For those who are less familiar, a user story is a lightweight way to define requirements, traditionally written on an index card. On the front, the product owner writes something like "As a X, I would like Y, so that Z." On the back, the developer will scribble notes about implementation details. An example might be: "As a sales person, I would like a list of my currently open deals, so that I can quickly click through to the deal details to determine my next action." On the back, a developer might reference which table holds deal information, what "currently open" means, etc.
One of the first things I noticed when I started working at Herrmann was how this format naturally follows the Whole Brain® model. On the front of the card, we list: As a WHO I would like WHAT so that WHY; on the back, notes on HOW.
Now, I'm pretty sure the team at Connextra who developed this particular format hadn't been exposed to the Whole Brain® model (although you never know – I'm always surprised at where our customers past and present crop up!) but this goes to show how many people independently stumble on something that looks similar to the Whole Brain® model when solving their own problems.
At Herrmann, our team quickly realized that extending the natural Whole Brain® properties of the user story format could help us make it even more effective. For each story we include a simple Whole Brain® WalkAround that looks like this:
A
WHAT: A 3-4 sentence description of what the system does now vs. what the system will do after this story is done. Often written like "Currently the system does X. This story is about making it do Y. Specifically 1, 2, & 3." with supporting sentences to cover more detail.
B
HOW: A bulleted list of implementation tasks, often getting into the detail of which code files might need to be changed. This will be updated and refined during the sprint, as new code changes are identified, but we try to define some high level bullet points during planning.
C
WHO: A list of the kinds of users impacted by this change and how they're impacted. We try to include named stakeholders who represent the user categories, so that developers can go straight to those stakeholders for questions and feedback.
D
WHY: A 3-4 sentence explanation of the motivation behind the overall story, as well as the "big picture" motivation behind the actual specific (ie. Why are we doing this story at all? Why are we doing in this way and not that way?).
It makes our stories slightly heavier than the average user story, but they're still fairly lightweight and much more comprehensive. I asked my team to tell me what their experience with this format has been, compared to more traditional formats they’ve seen at other jobs. Here are a few of their quotes:
The traditional format for me doesn’t really put an emphasis on the WHY / WHO; it might be implicit, but it was something that I felt was missing, and which is an important part of understanding the problem.
– James Naadjie, Software Engineer
Separating a bug out into the effects the user experiences, versus the causes underlying it and the intended solution is useful. For a new feature, there are slightly different benefits: separating the implementation from the overall purpose.
– Alexander Nye, Software Engineer
WHY can get short changed in the traditional approach. The expansion of detail in the D / Yellow Quadrant about why the feature is needed really helps the engineering team with the purpose of the request. This provides more opportunities to examine alternative solutions to the story and, I think, leads to a more innovative and collaborative process.
– Kim White, Director, Organizational Product Management
Most stories I read before at other jobs did not list who I could ask questions of.
– Charles Kuo, QA Engineer
These quotes really show how the Whole Brain® format moves a story from a list of requirements into a conversation starter by helping developers get a clearer sense of empathy. By having clear places to capture the WHY and the WHO, we are able to stay true to the agile tenant of “people over processes”. It builds on some of the original ideas in Agile, but allows us to go deeper with them by using a deliberate Whole Brain® WalkAround strategy.
How do you think writing Whole Brain® stories might help your organization? We’d love to hear from you and answer any questions about how it’s made a difference for our team!
At Herrmann, one of our key fundamentals is that we try to "eat our own cooking" and use Whole Brain® Thinking in our own work. This post is part of a series where our engineering team talks about how they use Whole Brain® Thinking in their own workflow.
This post is by our Platform Team Lead, Andrew Swerlick.
Share this entry
