Problem: I am not a software engineer. I am a Product Manager at Pivotal Labs and I don’t have an engineering or CS background.
When I joined a Pivotal Cloud Foundry Project with the EMC Dojo team, it felt like everyone doubted that I would be able to write the “technical” user stories that the team needed to execute on. And, even if I could write technical stories, no one thought they could be broken down into small and independent pieces of user value.
But, within 3 weeks, we had completely re-formatted the teams understanding of user stories. We successfully wrote iterative pieces of value that could be delivered at a predictable pace.
Let’s jump into the example.
How this story came to be: Cloud Foundry is working on local persistence in Diego cells. The EMC Dojo team, wanted to make sure that their ScaleIO product could be used for this persistence. So, we needed to create a way for the CF Diego cells to communicate with ScaleIO.
In short — we needed to translate between two APIs.
Based on the API documentation, we came up with a set of user stories that looked like this:
This story includes:
- WHY this story matters to the machines that the broker is communicating with and why it matters TO THE BUSINESS.
- A USER. The user can be a persona or a machine. In this story, Devon is a persona that would be using the curl command to bind to the service broker. However, Devon’s behavior is identical to the Cloud Controller, which is a Virtual Machine that would be making API calls. [Note, the cloud controller first appears a few stories later later in the backlog.]
- EXPECTED BEHAVIOR, both at the response level and behind the response. That means I included Sample curl in the request and response.
- RESOURCES leading the developer to the original API documentation so they can look at the larger picture if they’re new to the project.
- The story is also independent, complete, and small, just like the consumer facing example I wrote about last week.
Now, let’s talk about what this story does not include:
- It does not have any technical implementation details— I trust my team to figure out the implementation details.
- It does not include error responses, which are broken down into their own stories so they can be prioritized according to need instead of getting in the way of continued feature development.
- It does not include the un-doing of the response. The un-binding is a separate story, and it is a lower priority. We can release a software that can only bind and then later update the software with the un-binding functionality. This allows us to prioritize the stories and features that make the software releasable as early as possible.
A bunch of those user stories might turn into a backlog that looks like this:
A couple notes on the backlog:
- We started by focusing on the happy path: binding, connecting, creating.
- Then, we focused on the stories that were required to pass the minimum service broker tests.
- We made sure that each user story is an end-to-end, independent splice of value. This included a request from one machine, the expected response from our new broker, and the expected behavior from the second machine. This removes dependancies and means the product is releasable after any feature completion.
Interested in working on these types of projects? Join us!
What my backend and API user stories look like was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
