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).
Learn More:
- Writing Work Items – Agile PM book – Chapter 8: Planning Releases and Sprints > Refining Requirements and Estimates, location 3358.
- INVEST – Agile PM book – Chapter 8: Planning Releases and Sprints > Estimation poker > User stories and the INVEST approach, location 3577.
Guidelines for Writing Good Work Items:
Tips on writing good detailed work items for a product backlog.
|
VSTS Field |
Contents |
|---|---|
|
Title |
Keep it short but descriptive – 5 to 10 words |
|
Description |
Describe the work in as much detail as possible. For example: Story narrative:
Functional Requirements:
|
|
Acceptance Criteria |
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.
Independent
- To the extent possible, a story should need no other stories to implement the feature that the story describes.
Negotiable
- Not overly detailed. There is room for discussion and expansion of details.
Valuable
- 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.
Estimable
- The story is descriptive, accurate, and concise, so the developers can generally estimate the work necessary to create the functionality in the user story.
Small
- 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.
Testable
- You can easily validate the user story, and the results are definitive.