Getting Started
This is the second of a multipart series. In this article, we will be diving into User Stories and Task and comparing various features and explaining when and how to use them. We started the conversation in the first article about Epics, Features, and presented several ideas on how they can be used on a project. User Stories and Tasks are the natural next steps.
Also, if you missed the first article, you can read it here.
User Stories and Task Deep Dive
To reiterate a point from our last article. There are six main work item types. Epics & Features are scoped to provide senior leadership and product owners with a high-level overview and even have their own portfolio backlog. User Stories and Tasks are scoped to provide project managers, developers, business analysists, and testers with a lower level overview. Issue’s and Bugs round out the last two but will be covered in another article.
“User Stories define the applications, requirements, and elements that teams need to create. Product owners typically define and stack rank user stories. The team then estimates the effort and work to deliver the highest priority items.” – Microsoft
From this perspective, we begin to see why having additional work item types are important and how this architecture allows for a project to appropriately group work. One of the biggest frustrations encountered on a project is a client’s senior leadership mucking around with daily task management rather than delegating and trusting the team.
The Task work item provides the lowest level of granularity. “Tasks can represent different work to be performed – such as design, code, test, content, sign off.” – Microsoft
Similar to Epics, it’s entirely possible to develop code without Tasks. However, by skipping Task creation the development team misses out on an opportunity to utilize a robust set of planning and estimation tools; this practice is not recommended.
Deconstructing a User Story
Below is a graphic that we will use to explain the various aspects of a User Story and highlight recommended practices. Take a few minutes to review the graphic.
The only required field on a User Story is the Title. Every other field is optional but recommended.
- Description: should be populated with enough detail for a member of the team to be able to estimate the level of effort to implement the User Story
- Acceptance Criteria: clearly state the criteria to which the User Story can be marked as complete
- Classification or Value Area: allows for grouping by either Architectural or Business
- Story Points: way of estimating the amount of work required to complete the story but is not a direct correlation of hours;
- rather it represents a bucket of hours per point.
- Priority: the importance of this feature:
- required to ship, required to ship but address later, or optionally based on resources, time, and risk.
- Risk: a subjective range describing the uncertainty of completing the User Story.
Decomposing a Task
Below is another graphic that we will use to explain the various aspects of a Task and highlight recommended practices. Take a few minutes to review the graphic.
Similar to a User Story, only the title is required.
- Description: should be populated with enough detail for a member of the team to be able to estimate the Effort to implement the Task
- Priority: the importance of this task:
- required to ship, required to ship but address later, or optionally based on resources, time, and risk.
- Effort (Hours)
- Original Estimate: the amount of work required to complete a task. This field does not change after assigned.
- Remaining Work: the amount of work remaining to complete the task. Update this field as work progresses.
- Completed Work: the amount of time spent on a task.
- Activity: the type of activity this task represents when estimating sprint capacity by activity.