Managers that don’t understand user stories write them like this.
As a user I want to choose my engagement mode so that I can listen to the radio, explore or plan trips, or travel.
As a user I want the app to remember my mode and state so that when I background or relaunch the app I see the same screen as the last time I used it.
As a user I want the app to have a consistent branding and experience across all the channels, follow user experience and implementation best practices described in the heuristic evaluation, and leverage the appropriate interaction/visual design paradigms for each channel so that the app and website are performant, intuitive, and delightful on iOS and Android devices as well as desktop browsers.
As a user I want the app size to be 100 MB so that it is compatible with iOS OTA downloading footprint size limits for cellular installations.
As a user I want the app to be mindful of data and processor/memory usage, utilize data compression and other efficient downloading/caching/backgrounding strategies, and have graceful degradation features so that the app doesn’t exceed the average cellular data plan or drain the device’s battery and also has good performance and audio quality regardless of my network type or connection strength.
Capturing a vision is hard. For folks that operate in the abstract a conversation might be enough. For more concrete personalities it feels like we should explain exactly what is desired so that it is written down with precision. Somewhere in the middle of this spectrum exist enough information to get to the next meeting. For me that is the user story.
The magic of agile development is iterations. We are not going to have just one meeting where the requirements are handed down and then the engineers build what was specified. Instead we are going to have one meeting to decide what is going to be built and when those first user stories are going to be completed. Then there will be a show and tell and we will go through this process again.
To write good user stories it is good to think about it with the INVEST mnemonic created by Bill Wake.
Independent : Is the story dependent on another story?
Negotiable : Can you push back on this story and discuss it with the business owners?
Valuable : Does the story provide value to the stakeholder?
Estimable : Can you estimate how many days you can do this story?
Small : Can you break the story into multiple stories until it fits an agreed on minimum size?
Testable : How are you going to test that this story was completed?
If you look back at the original stories I started this article with you can see that there are many of these questions that cannot be answered and therefor they need to be rewritten.
I think what really stands out for me is that these stories are written from what the manager wanted and not from what the customer wanted. This is a very easy mistake to make. It requires discipline to remember that the product is being built for a customer and each story needs to focus on what the user wants and why.
Requirements documents kill creativity and slow the product design. They make the assumption that we already know everything we are going to know and can therefore decide all of these things now. It’s easy to get into the mindset where you just tell them what you want and expect that to be what they build. But, software has gotten faster to rewrite and that changeability is what makes it so powerful. In software, it changes overnight so only plan one sprint at a time because you never know what will happen next.