A question story is a specialized
specific to data-oriented requirements.
A question story should be small and ideally implementable within a few hours or days
by the person(s) taking on the work.
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:
As a [Role] I want to know [Something] by [Timeframe] because [Reason]
- OR -
As a [Role] I want to know [Something] because [Reason]
Are Question Stories Complete Requirements?
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.
- Captures data needs in an implementation-neutral manner.
- Simple, easy-to-learn technique.
- Supports active stakeholder participation.
- Useful to small, vertical slices of value.
- Needs to be supported with other assets to capture data source information, calculations, access control concerns, and potential visualization strategy.
- Not the data model strategy that traditional data professionals are used to.
When to Adopt Question Stories
When you are identifying stakeholder needs for information.