INVEST in your User Stories

User Stories are just one type of Product Backlog Item (PBI).

TIPS:

Independent

• • This is important, so that they can be prioritised without worrying about ordering due to dependencies.  If you're struggling to make your Backlog Items independent, consider whether you can split the epic or the user story up in a different way.  Also consider the fundamental value proposition of this piece of functionality, try abstracting the User Story to better describe why the user wants to achieve their goal.

  • To clarify, tasks are NOT PBIs, they only become items within the Sprint Backlog as a PBL item is broken down into smaller, workable chunks.

  • I is Important to be able to make agility and prioritisation easier.

Negotiable

If there isn't scope to negotiate, this should be a red flag, a sign that the development has inherent risks.  If you're applying agile techniques in a non-software development environment, this may be a sign that your items on your "To Do List" are very much tasks (the How) rather than the What & Why (What needs to be achieved as an outcome not output and Why it's beneficial to the business or customer to do so).  Ideally the details of the What and definitely the How should be up for discussion and refinement throughout the planning and even the execution (as you may uncover more unknowns, complexities or ambiguities that make the task(s) much harder or more effort).

This gets a bit murky because it's really helpful if, as an item starts to come towards the top of the backlog, you have a basic understanding (and shared agreement) of how this will be achieved.  You need this to be able to come up with a meaningful estimate AND to be able to spot any ambiguities that may require investigation or input from other stakeholders (both of which would cause impediments and delays if not identified until the work was actually started).  We want to be able to start working on an item and to be able to keep working on it (with minimal distractions or delays) until it's done.  It is much more efficient to work without having to context switch and to possibly enter the flow state.

Having the opportunity/empowerment for negotiation is also part of the shift from Command and Control to High Ownership - High Performing teams.

Remember, the main point about agile techniques and its ethos is to manage uncertainty. 

Valuable

Business value comes in all shapes and sizes.  Whilst obsessing over the needs of users and customers is central to success, focussing on this alone isn't going to help your business survive.  Using some form of portfolio approach, even something like a Balanced Scorecard, is a good way to be able to help all PBIs have a clear value proposition.

Estimated

Firstly, focus estimations on Size / Effort.  Have a sense of how much effort something will be, then this can be used to understand time, cost and resources.

Remember: Estimate size, calculate duration.

Small

Working from a prioritised backlog of small user stories allows a team to get value and high-quality feedback on frequent intervals. Many teams struggle to split large user stories and features into good, small stories. Instead of ending up with small vertical slices through their architecture, they get stories that look more like tasks or architectural components and fail to experience the value or feedback small stories should provide.

A backlog of small items aids with prioritisation because several small, valuable items from different Epics or even different types of backlog items (such as Technical Debt) can more easily be 'interleaved' on the backlog.  For example, you don't have to try to prioritise dedicating two sprints worth of effort on a technical improvement initiative over a product feature.  All PBIs (product backlog items) should be small, not just the User Stories.  If prioritisation is constantly hard, odds are the items aren't small enough and aren't well aligned to different types of business value.

Estimating is hard and chunking things up into smaller items helps to improve estimation accuracy.  If your estimates are too inaccurate to be of use, break items down even smaller.  Quite often optimists don't break items down and as such, not only are they likely to underestimate things anyway, but they tend to disproportionately under-estimate large tasks.

Testable

Acceptance Criteria: This is the common way of expressing more detailed requirements, still typically from the users point of view.  However, they can be written in different formats. There are two common ones, and the third option is to devise your own format:

1. scenario-oriented (Given/When/Then)

2. rule-oriented (checklist)

3. custom formats such as:

• Specification by example

• Mathematical / Algorithmic

Acceptance Criteria are specific to the User Story.  Read more here.

Definition of Done: There needs to be no uncertainty as to whether an item is done or not.  In scrum, there is a Definition of Done (DoD)...a small set of criteria that must be true for the item to be declared 'Done'.  This will always have something in it about approval, who needs to approve and against what criteria.

DoDs are generic and apply to all stories. 

Conclusion

The INVEST Criteria helps a Product Backlog to follow the D.E.E.P. criteria and as you can see, helps foster a working environment in which high performing teams can thrive.

Related Pages:

• User Stories

• Acceptance Criteria

• Business Value