This month I was going to do the usual, write a summary about the Scrum Alliance webinar for March which was: Make Your User Stories ‘Ready’ to Get to ‘Done’, by Ellen Gottesdiener, from EBG. Instead, I decided to make this one shorter and discuss one of the key subjects she discussed: 7 product dimensions.
Most of us already know the typical user story structure: As a ____ I want to ____ so that ____. But this kind of user story usually lacks detail and doesn’t ensure that everyone in the team has a shared understanding of its requirements. Without a shared understanding, requirements will be incomplete, done wrongly, or just result in the story being postponed for a different sprint; in other words, they aren’t ready to be part of a Sprint. The 7 product dimensions can help us ensure that the user story is ready.
To explain how they do that, I’ll use the example Ellen Gottesdiener used in her webinar:
As a concert goer, I want to use dining discounts so I can enhance my concert experience.
With the story above, a lot of different questions arise:
Who is that user, is it any type of concert goer? What does that “use dining discounts” mean? What type of dining discounts? Can anyone use that discount? What’s the platform where the concert goer will use the discount? And many others. Here’s another version:
As a Super Fan concert goer, I want to search for concert-related dining discounts so I can enhance my concert experience.
With this second try, some of the previous questions are explained, but plenty others are left unanswered. Which is why for this example, Ellen Gottesdiener suggested the following:
As a Super Fan concert goer, I want to search for concert-related dining discounts so I can enhance my concert experience.
- Only member can search for dining discounts
- Only active dining discounts can be searched
- iOS, Chrome v50
- Search query and result
- Available 95% of time
What she did there was make sure the 7 product dimensions were answered in the user story.
User: people, system, devices that interact with the product
Interface: how users connect to the product
Action: capabilities offered to the users
Data: data and information the product retains
Control: policies, rules, and/or any regulations the product enforces
Environment: the technology platforms (hardware and software platforms) and in some cases the physical properties of the product.
Quality Attributes: properties that describe the products operation and development, security, usability, reliability, response time and testability.
As you can see in the image above, the dimensions were classified as functional and nonfunctional requirements (engineer terms). But that doesn’t mean that the nonfunctional don’t require any functionality. You can also see that each dimension has a different color and image; these are very helpful when refining those backlog items.
When defining the 7 dimensions for a user story, it is again, very important that the whole team fully comprehends each one to avoid setbacks further on in the sprint due to a misunderstanding of any requirements.
Looking for help to convert your dragging sprints into short, effective bursts of productivity? Shoot us a message or give us a call, one of our expert agile coaches will get in touch.
