When I start working with a new client at Pivotal, I always share a few notes for the product manager I pair with, and now I'm sharing them here. To get started with Pivotal-style Extreme Programming (XP) read Extreme Programming Explained by Kent Beck. This is also a good quick overview.
I start by telling PMs that stories are intended to communicate not only with the developers but also with stakeholders, who are usually not technologists. That's why at Pivotal, we use lay language when describing the proposed work. In XP, it's always the stakeholders (with the Product Owner as the lead and arbiter) who determine the prioritization of the backlog. To assist them we, the PMs, may make suggestions. Also, we have context on any tech requirements for prioritization.
To reduce cognitive load, we use a template for writing stories. It starts with a scenario: what a user is trying to accomplish, for instance:
- As a <User Persona>
- I want to <do a thing>
- So that <business value>
Tying every story back to business value requires the stakeholders to know exactly how building this feature will help their bottom line. Usually, that's done by directly linking it to a Business Strategy. Once complete, this feature (or set of features) can be used to measure whether we're building the right thing. With metrics, we can see our progress, course-correct if we're off track, and prioritize the next features.
Next come the Acceptance Criteria, for which we use this template:
- GIVEN
- WHEN
- THEN
The developers will use these criteria to write their tests (we practice Test-Driven Development) and to know when they're done, and the PMs will use them during acceptance. We always try to make our stories the most efficient embodiment of adding business value.
Here’s an example.
Scenario:
- As a Thirsty Introvert
- I want to buy a can of soda from a coin-operated vending machine
- So that I can relieve my thirst without interacting with Humanz
Acceptance Criteria:
- GIVEN I have exact change
- WHEN insert my coins
- THEN a single can of soda is delivered.
This story adds business value because the Thirsty Introverts we interviewed told us they are more likely to buy a can of soda if they can do it using a machine. Notice this story doesn't address electronic payments, making change, or soda flavor selection; these can be covered in future stories. Notice also that its end-to-end for a specific workflow. It isn't about the UX of the entire display panel, for instance; that part alone doesn't deliver business value.
It’s easy to imagine the next story might be something like,
Scenario:
- As a Thirsty Introvert
- I want to see a selection of available soda flavors
- So that I can choose one.
Acceptance Criteria:
- GIVEN a selection of soda flavors
- WHEN I choose one
- THEN a single can of that soda is delivered.
This story adds business value because the Thirsty Introverts we interviewed told us they are more likely to buy a can of soda if there is more than a single flavor option. It requires a more complex UX; your designer will add assets to the story so the developers can refine the front end in tandem with the backend logic. With each new story, the assets will be updated, so that when the developers complete a story, it will be useful to the users and beneficial to the business’ bottom line.
Stories Add up to Epics
Both of these stories might be part of an Epic called, Soda Vending. Depending on the scope of the project, there could also be Epics titled: Machine Maintenance, Location Licensing, and Payment.
Organizing stories into Epics is a way to clearly document different tracks of work. This is key: if there is more than one pair of developers on your team, it's the PM's responsibility to maintain at least ‘n’ tracks so they can work simultaneously in the same codebase without stepping on each others' toes. Better yet, aim to have ‘n+1’ tracks so if one is blocked, your engineers can stay productive. And it all comes back to stories: you can only have productive multiple tracks if you have clear user stories and scenarios.
Not every story in an Epic must be completed before starting on the next Epic. In fact, it's likely that the stories deep in the backlog wouldn't deliver sufficient user value to justify the cost of building them. You, the PM, should always be grooming the backlog to reflect the relative value of each story. An available XP engineering pair will take the story that's at the top of the backlog, so if you rearrange the pointed stories during the iteration, it shouldn't matter to them. Just be sure you've communicated the new priorities to your Product Owner/Stakeholder.
These are some of the concepts that can help you get started. There are more resources available on the Pivotal website and the product manager section of our Practitioners’ Blog.
