Question Stories: Extending User Stories for Data
A question story is a specialized user story specific to data-oriented requirements. Question stories should be small and ideally implementable within a few hours or days by the person(s) taking on the work. Question stories describe vertical/thin slices of deployable value.
The following are examples of question stories:
- As a sales manager I want to know the level of sales by my team by the end of each day so that I know where we stand.
- As an instructor I want to know the certification pass rate of my students so that I can update my seminar marketing message.
- As a restaurant owner I want to know the common combinations of menu options being ordered so that I can identify potential specials.
- As a city councilor I want to know the number of complaints about road quality so that I can determine where we need to focus our repair efforts.
Why Question Stories?
Question stories are used to capture requirements for data-oriented initiatives, in particular data analytics and data warehouse (DW)/business intelligence (BI) solutions. Because data initiatives exist to help people leverage data to make better-informed decisions, to answer questions, it makes sense to identify what questions people hope to answer. This enables you to focus on the outcome, answering questions, rather than the implementation, the structure of the data.
How to Capture Question Stories
Question stories are written in one or two formats:
– OR –
As a [Role] I want to know [Something] because [Reason]
Are Question Stories Complete Requirements?
To paraphrase Ron Jeffries, a question story is a reminder to have a conversation with your stakeholders. I consider a question story as a start at an understanding of what your stakeholder needs you to provide. You need to collaborate closely with them to explore what they really need to answer, why they need to answer this question, when they need the answer, and how they would like the answer provided to them.
How to Identify Question Stories
Question stories, like other agile models, are best identified with your stakeholders. Better yet, because question stories are so straightforward, your stakeholders themselves can often write them. Never underestimate the power of active stakeholder participation.
To identify question stories, I will often ask people:
- What keeps you up at night?
- What do you wish you understood better?
- What would you like to know about the outcomes being achieved by your team?
- Do you know why your customers do what they do?
- Do you know why your colleagues do what they do?
- What decisions to you regularly make?
- What will you need to decide upon soon?
Definitions of Ready (DoRs) for Question Stories
Many agile/Scrum teams have a DoR that defines the minimum level of quality of the work that needs to be put into a story before the team is willing to work on it. This is true of question stories as well as of more general user stories. The DoR for a question story may include, but is not limited to:
- Data element definitions
- Calculation rules/algorithms
- Data source mappings
- Data source access information
- Desired format/platform/media for the answer
- Stakeholder contact information
Question Stories in Context
The following table summarizes the trade-offs associated with question stories and provides advice for when to adopt them.
Table 1. Question stories in context.
|When to Adopt Question Stories
|When you are identifying stakeholder needs for information.
This book, Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working (WoW) – Second Edition, is an indispensable guide for agile coaches and practitioners. It overviews key aspects of the Disciplined Agile® (DA™) tool kit. Hundreds of organizations around the world have already benefited from DA, which is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your WoW. As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context.
I also maintain an agile database books page which overviews many books you will find interesting.