By Sogol Fathian
Recently I gave a talk about writing technical stories and ways I have found to slice user stories thinner at Product Camp Toronto. I thought it’d be good to share some ideas from that talk here as well.
I work as Product Manager for epost which is one of the biggest online document delivery and management systems within Canada. epost allows users to view, pay and manage bills online and roughly one in ten Canadians use it to view their pay stubs, utility bills and tax statements among others. Right now I am in charge of leading a scrum team to redesign epost to improve web and mobile user experience. I am also responsible to revamp epost API service calls and to integrate them with Canada Post, banks and mobile apps.
My team is one of the first teams working Agile within Canada Post, so we are all new to the concept of finishing user stories within a two week sprint. And after the first few sprints I realized that we were constantly behind schedule.
Our flow for getting a story done looked something like the following:
Creating API calls and gateway calls would take half a sprint and front-end will work on the last leg of sprint to get it done. So when the story was ready for QA we were out of time and stories kept piling up to the next sprint!
I also realized during our sprint planning and release planning a bunch of tasks get discovered and brought up that are not identified earlier. By the time these tasks are done, we are already late with the sprint. It was clear to me that I needed to write smaller stories but how?
Write Technical Stories (when necessary)
I decided since any given back-end service call will be consumed by multiple end-points it makes sense to slice a story further into an API-specific one and a front-end/UI one. API story is still valuable and independent (sort of) but it can be estimated and worked on by itself. This way I could prioritize the API story ahead of front-end story to provide much needed time for UI and QA to be done.
This was great however I didn’t know how to write user stories about API, web services and other technical stories that are not necessarily user facing. More importantly I was struggling to fit the story into “As a user I want to — so that I can —” template.
“As a front-end developer I need to supply mail list data so that it shows as a list view of mails” sure sounds weird!
I came across this excellent article that confirmed my belief not to fit the story into a template when it doesn’t fit. So for technical stories I clearly write Who the end-points consumers of the API call will be, What is expected acceptance criteria of each of the end-points are and what it the expected output of this API is and finally Why this API call is important to develop. I talk to developers to understand what does API generate, how it can be validated and make sure there is alignment on acceptance criteria prior to grooming session. From my point the story is usually done once I can see API call and the data generated in Swagger and all the security criteria is met.
So a user story that looked like this before:
As a Chief Household Officer, I want to filter mail by service provider name so that I more easily find my mail
the API story will look like this:
We need an API call used by Canada Post, native app and our bank partners to filter mail by a service provider so only mails by that provider shows up
- Verify that the request get thru the service layers and receive a reply within 2 seconds
- Verify that the request has necessary Oauth permission to be exposed externally
- Verify that the request is generated in both XML and JSON formats
- Verify that records are returned from oldest to newest
Separate Success and Error Stories
Another trick I’ve found effective to write smaller stories is to focus one user story only on the happy-path, while writing other stories for when things went wrong, edge cases. For example for file creation user story write one story specifically about creating a file without any problem but write several more stories to cover the file name maximum character, acceptable characters etc.
I would love to know if you have other ways to slice a story further. Please share them with me in the comments below!
By Saeed Khan
First off, thanks to Rich Mironov for inspiring the title of this post. He was wearing a t-shirt from the first ProductCamp Silicon Valley with a very similar phrase on it.
ProductCamp Silicon Valley was this past weekend. Held at the EBay complex in San Jose, over 500 people showed up on a nice sunny Saturday to network, share their stories and learn about product management, product marketing, innovation and other such topics.
I’ve been to a number of camps in New York, Boston, Austin and of course here in Toronto, but this is the first time I’ve attended the event in the Valley. Yes, that’s me on the right getting ready for my talk. Click on the image to enlarge.
It was good to see some old friends such as Barb Nelson, Sue Raisty-Egami, Scott Gilbert, Steve Johnson, Cindy Solomon and of course, the aforementioned Rich Mironov amongst others.
I gave a talk on Product Management Metrics. Steve Johnson spoke about Shaggy Dog stories. Barb discussed Launch Readiness (or lack thereof in some cases).
Our presentations are below, as well as a link to a Storify story by Cindy Solomon on the event. If you were there and have other links to the event or other presentations, leave them in the comments.
Tweet this: One day at Product Camp (Silicon Valley) http://wp.me/pXBON-3OY #prodmgmt #svpcamp
Are you going to ProductCamp Silicon Valley this year?
It’s March 23rd at Ebay in San Jose.
I plan on attending and I’ve proposed a couple of talks as well. Steve Johnson, another contributor here is also attending and has proposed a talk.
You can see and vote for these talks and others on the Product Camp sessions site, or just click on any of the links below to get to the voting page.
Product Management Metrics — How to be the CEO of your product by Saeed Khan
One of my proposed talks. In it, I put some structure around managing products in a more holistic manner and present a model that can be used for virtually any product.
Stories about Product Management – by Steve Johnson
Steve is a great storyteller and always has some great insights to share
How to Become an Independent Product Management consultant by Sue Raisty-Egami
Sue is a really dynamic speaker and has been an independent consultant for a number of year. I’m going to try to attend this session myself.
No More Superheroes – How to build an effective and scalable PM organization – by Saeed Khan
My second proposed talk. Here I present a structured approach to defining differntiated roles within Product Management and a way to grow the org so it best addresses the needs of the company as well as the team members.
Understanding the next job up — and getting promoted – by Rich Mironov
Rich is a true high-tech veteran who has spent years “in the trenches”. He has great insights to share and all I can say is I wish I had attended a talk like Rich’s when I first started in Product Management.
Thanks for the support.
And if you are a reader of this blog and will be attending ProductCamp, I would love to meet you if possible.
Leave a comment here and then let’s try and connect at the camp.
Tweet this: Heading to ProductCamp Silicon Valley? http://wp.me/pXBON-3NS #prodmgmt #svpcamp
Silicon Valley Product Camp 2012 is this coming weekend! March 24th at eBay’s office at 2161 N. First Street. You went to all the trouble to register and vote for sessions, so don’t forget to show up! If you’re like me make sure to warn your spouse so they aren’t shocked that you have plans for 8 AM on a Saturday. If you didn’t manage to register in time, make a note to sign up next year or try to get to one of the other awesome Product Camps taking place around the country or around the world. Check out the top proposed sessions ahead of time to see what catches you interest.