Do you keep user stories about doing something
Curious to hear how different people approach their user stories. I've never been a fan of backlogs where everything is shoehorned into user story format, but equally I can see their usefulness in certain scenarios.
I'm interested as to whether people tend to use user stories to describe a user doing something, or whether they also use them for something they want the system to do, or a quality they want it to have.
Let me use an example.
As a B2B account manager, I want to see the new releases on the webshop before they become available to purchase, so that I can talk to my customers about upcoming new products.
Now this is not the user doing something per se, but equally it's a perfectly valid thing for them to want. I guess my challenge comes in how this would actually be developed...
We know we'd have to build an integration to pass product data from the PIM (product information management) system to the ecommerce system. Within this product feed we would be passing all the product attributes, some of which are visibility date & launch date (i.e. when should it be visible vs purchasable). This integration would be built as a single piece of work, and then the ecommerce system would display or not display products based on these attributes.
But it just so happens that there is another user story in the backlog
As a B2B account manager, I want to see all the products available for purchase so that I can decide what to add to the order.
I think realistically the development work to support these two stories wouldn't make sense to split, and would be handled via the same integration & presentation rules. However I guess my question is, they could be refined separately & pulled into separate sprints. And I wouldn't expect the PO to split user stories based on how they are going to be developed because they wont necessarily know that, and feels like thats moving away from the users perspective of what they want.
How do you guys manage this kind of thing? And do you tend to use user stories for this kind of thing?
A user story is a placeholder for a conversation about a potential requirement. That's it, and if they are the chosen means of expression for a Product Backlog item, that's how they ought to be used.
The Developers on a Scrum Team ought to be acknowledged, encouraged and respected as creative professionals. Give them the placeholders so the best solution can emerge, remembering that once on a Sprint Backlog, user stories are just a forecast of work for meeting a Sprint Goal.
My two cents: the ubiquitous user story isn't useful for every PBI, and Scrum does not require us to use it or any other format. User stories work best when we actually need to build some empathy for the end user, and as stated above, it triggers a conversation between the PO and Developers. User stories don't work well for defects and non-functional requirements. In your examples, I actually don't have a problem with using the user story format.
Job stories are a nice alternative when there is less focus on who the user is performing the job, as it applies to every role. You can Google Job Story. The format is When <situation> I want to <motivation> so I can <get some expected outcome>.
Example: When we pre-release new products to the webshop, I want to preview them before a customer sees them, so I can be prepared to talk to my customers about upcoming product releases.
Your example of not being able to get something done in one Sprint may signify the PBI is an epic. An epic may take more than 1 Sprint, but that's okay. Perhaps that epic breaks down into multiple PBIs. Scrum doesn't require us to release every Sprint (although it would be great if you could). There are many splitting patterns (Google Humanizing Work for their template), and where there's a will, there's a way. I find it very helpful to include the Developers in the splitting conversations.
We use to have user stories that where not written the perspective of the user however what we notice to happen is that the scope of the stories became very big and they started to turn into epics, also often things that needs to be done just got added to the backlog making it very big and unmanageable. What we now do is try to make the stories from a user and sometimes the users are ourselves as developers and that has helped us to keep the stories small, testable and finish-able. As you mentioned there are sometimes couple stories that make no senesce to plan and finish separately as they can be done together as part of the same thing, in that case we just try to plan and develop them together while keeping them separate stories so that they can be tested separately. This also helps with when something does not meet the expectation in one we don't block the other story from releasing.