Quick tips on writing good Epics, Features, Stories and any other work item types and using the INVEST technique to break down work in to smaller pieces.
Written in 2016-2017:
This is part of a series of articles that I originally wrote in 2016-2017 and were only published on private internal company wikis. I am publishing them publicly for the first time in 2019, here on my blog.
Written for Microsoft’s VSTS:
Some content is written for Microsoft’s Visual Studio Team Services (VSTS), as it existed in 2016-2017. VSTS was renamed to Azure DevOps in 2018 (WikiPedia).
Guidelines for Writing Good Work Items:
Tips on writing good detailed work items for a product backlog.
Keep it short but descriptive – 5 to 10 words
Describe the work in as much detail as possible. For example:
Details on what it means to be complete. For example:
Use the INVEST Technique to Write Good Work Items:
Tips on breaking down work items in to smaller pieces using the INVEST technique.
- To the extent possible, a story should need no other stories to implement the feature that the story describes.
- Not overly detailed. There is room for discussion and expansion of details.
- The story demonstrates product value to the customer.
- The story describes features, not a single-thread start-to-finish user task.
- The story is in the user’s language and is easy to explain.
- The people using the product or system can understand the story.
- The story is descriptive, accurate, and concise, so the developers can generally estimate the work necessary to create the functionality in the user story.
- It is easier to plan and accurately estimate small user stories.
- A good rule of thumb is that a user story should not take one person on the development team longer than half of a sprint to complete.
- You can easily validate the user story, and the results are definitive.