At Boomering we’re getting ready to go into development. I’ve hired a group of 6 developers and were about to set off on building the product. Over the last three weeks I’ve been spending a lot of time writing user stories as my friend and collaborator has put together the technical specification. We’re going to approach the developers with these two items and then manage two week sprints with the developers. While he built out the flow diagrams and the data base schema I spent my time on user stories. My process is simple.
Get Your Design Down First
Initially I started writing stories before I had my design done. They were awful wordcel bits with tons of if / then logic in them and an absolute mess. After banging my head against the wall for two weeks writing these I took a break and came three weeks later with the design completed. I was disgusted with my stories. They were awful and didn’t make any sense compared to the design. Doing the design led me to prune a lot of what was in my head. The final design came as a prototype, and clarified a lot of what I wanted versus what I needed. That made writing the user stories much easier for me and hopefully clearer for the developers.
Keep it simple, stupid
A user story should be one sentence. Your acceptance criteria should be bullet points. Very rarely should you have any formal logic and multiple screens in a single story. I’m sure where I ended up was 10X better than my first iteration, yet I’m also sure the stories will be simpler by the time the developers and I have gone over them .
Include screen shots of your design
I pasted images of the screens the user story was written for in each user story. That helped me clarify my thinking even further. Writing stories on the designs also acts as another purifying round. You come out with a much clearer view of how things work. While writing these stories, there were several “Oh Shit, I didn’t think about that case” moments. Those are good to get out of the way early. You don’t want to start spending engineering time and then run into problems. Use those questions to brainstorm solutions straight away.
Measurements
At the end of my user stories I include what I want measured on each page. This might not be necessary, but it helps me think through what I want to track and how users are going to use the app and what metrics are actually important versus what are nice to have. You can not track everything at an MVP level, so think deeply about this.