One of the aspects of being a Business Analyst Consultant that I feel a keen responsibility for is asking good questions. By that, I mean asking questions that are both relevant and relatively easy to answer.
When I started out my career as a BA I honesty did not think much about what questions to ask. If I were assigned the job to gather requirements for a project, I would just ask them what their requirements were. “What do you want?”, I’d simply ask, or “how do you want us to design the system?”, or “what are the features, functions, reports, or screens you want?”
It was not until after joining IAG that I gained an appreciation for what good questions meant — and the skills, techniques, and tools to be good at it. It is here that I learned that requirements discovery was neither a eureka moment nor accomplished by randomly searching and gathering (like you might as a child hunting for Easter eggs.) I learned that the secret to discover something was not in one magic question but a series of methodical ones – that the path to discovery was journey not a jump. I learned that there are many ways to get there. Some roads are easier and better than others, and some methods of transportation are better than others. The trick is having a good roadmap, using the best methods for the trip, and having a good pilot and navigator.
To add to the challenge, the path is usually neither set nor simple. We always like shortcuts if we can. Unfortunately, good analysis can rarely be done by survey or a fill-in-the-blank template. It is possible. Sometimes you (or your stakeholders) may be able to easily fill-in-the-blanks of a user story: As a , I want so that . Certainly, it is better than just asking, “What do you want us to do for you?” But as powerful as that user story format can be, when things are a bit more VUCA (volatile, uncertain, complex, and ambiguous) as most applications are these days, you might need more than just that to generate the conversation and good stories, requirements, or acceptance criteria. That is why the world still needs professional business analysts. And that is why today’s business analysts use aids and methods to support them: Aids like the User Story Discovery™ Canvas that provides a visual framework to collaborate on a User Story.
“If you want to understand anything, you mustn’t try and understand everything.” Gerald Weinberg
The User Story Discovery Canvas provides the foundational and contextual building blocks to assist an Agile Team understand what the user story is and what we need to know to plan and begin working on it. Like Gerald Weinberg’s Lump Law, it recognizes that we should not try and define everything about the story, but if do we want to try understanding it, we should break it up into a manageable set of the most pieces we need to know. The simplicity of the user story is in focusing on the what, who, and why. The Canvas does the same. The most important (and first) sections of the canvas to discuss are those same building blocks:
- The Story Scope. The elements (e.g., features, functions, scenarios) that frame the boundary of the story and help clarify what the story is about (for the “I want” portion of the story,)
- The User Role(s). The types of users wanting this functionality, and
- The User Value. The reason(s) why the user wants it.
In addition to these foundational building blocks are additional contextual ones such as business value, business drivers, constraints, solution considerations and of course, acceptance criteria, that can help the team ensure a necessary and sufficient (i.e., just enough) understanding of the story to begin solution design and development.
Just as the user story card is intentionally designed with limited space so that the focus is on the conversation rather than documentation, the canvas is also limited in size so there is enough room for sticky-notes and bullet points but not intended for functional specification type detail.
The power of the canvas is in providing a set of elements to discuss (and questions to ask) as well as to provide a visual framework (the canvas) to help facilitate the discussion. Where the card alone looks for the “one” answer to the user role, or goal, or reason, the canvas provides room for many answers from the team.
From a facilitator’s point of view, we want to keep our discussion focused. And the canvas allows that with delineated sections. Secondly, we want engagement and collaboration which the canvas supports by encouraging multiple answers; not shutting down the conversation with the first response to fill-in-the-blank.
During in-person sessions with the canvas at the front of the room, or virtual sessions with collaboration tools like Mural or Miro, user story writing workshops take on an entirely different (and fun) dynamic –with participants placing their sticky notes on the canvas. As a BA or PO, I leave these sessions with far more confidence that we have a better story that is better understood with the kind of participation and focused discussion the canvas affords us.
Here is the link to download the User Story Discovery Canvas from the IAG website. To learn how to use them most effectively, you can attend online classes like Agile Business Analysis or the IAG Business Analysis Boot Camp — or contact IAG to facilitate, coach or mentor your team through virtual or in-person Story Writing Workshops or Backlog Planning meetings.
Related Articles, Resources and Assistance
- Blog Post on IAG’s series of Discovery Canvases
- The User Story Discovery Canvas Template
- Training courses that provide instruction on using Discovery Canvases: The BA Boot Camp, Agile Business Analysis
- IAG Engagements that employ Discovery Canvases: Story Mapping Workshops, Agile Release Planning and Product Backlog Meetings, Product Vision and Scoping Sessions, and Requirements Discovery Sessions