The more specific a product backlog item is, the more efficient a team will be when working through the items. All items should contain a concise description, if you imagine the reader has zero knowledge of the system would they understand what you are asking?
Good briefs are user-focused. In agile, user stories are actually the name used to describe the brief/ product items. If you follow a structure of As an XXXX, I want to XXXX so that XXXX it is easier to capture the business value and specific type of user/ requirement.
For instance, rather than ‘Allow finance application to be filled out online’, we could use:
As a customer
I want to fill out my finance application in the comfort of my own home with a cup of coffee
So that I can have the peace of mind I will be accepted for finance and can reduce the time I am in a dealership on a weekend
As a sales executive
I want to be able to review the finance application of weekend prospects
So that I can prepare the paperwork required in advance and help eliminate time the customer needs to be in the dealership
As a marketer
I want to see a list of all customers who filled out the finance application and didn’t buy a car
So that I can send out an email campaign to generate appointments if they’re still looking to purchase
This provokes a conversation and so many more questions than the one-liner brief would. This is optional, we could still have a great brief away from user stories but it could be something worth considering. The key is that we focus more on what the scope is rather than how to develop the solution. It should provide enough detail to create a shared understanding of what is required but won’t go into specifics of how to develop it. It is open-ended and allows the team (product, UX, development) to all contribute and offer their expertise on how to achieve the best possible outcome.
The Invest acronym is a widely accepted set of criteria which helps assess whether the user story is good or not.
- Independent (of all other stories). If there are dependencies, or other features required then these requirements should also be added to the backlog (and linked if required)
- Negotiable
- Valuable
- Estimable
- Small (ideally no greater than 5 days worth of work, it needs to be able to be delivered within a sprint, ours are two weeks in length)
- Testable
Always consider the none functional requirements while estimating PBIs, these include but are not limited to tracking, SEO, compliance and page speed considerations.
Defining user acceptance tests upfront can help with estimating the complexity of the PBI.
Given
When
Then