Contents

Writing & Breaking Down Tips for Features, Epics, Stories, Etc.

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.

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
(to make it readable & useful on board views, reports, etc.)

Description

Describe the work in as much detail as possible.  For example:

Story narrative: 

  • As a <user>
  • I want to <action>
  • So that  <result>

Functional Requirements:

  • When I do this: <action>
  • This happens: <result>

Acceptance Criteria

Details on what it means to be complete.  For example:

  • How functionality should work
  • Deliverables
  • User or machine interactions
  • Results
  • Etc.

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.
Need an Agile Expert ?

Looking for an expert in Agile Coaching, developing & leading Agile transformations, Agile tools, DevOps strategy and Scrum ?

Send me, Ken Adams, a message on LinkedIn and let’s talk.

Subscribe

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d