Azure DevOps has multiple ready made work item types, and they are usually more than enough to run normal agile software development. In this post I will cover what are the regular work item types and how they should be used.
4-Tiers
By default Azure DevOps has four tiers of work items: Epic, Feature, User Story and Task/Bug. Bug can be configured to be in User Story level or in Task level.
Issues are independent from these tiers, so I don’t count it as a own tier.
Epics are the top level work items and they are actually the most difficult ones to wrap around. First I want to say that most of the companies don’t use Epics, or if they use, they provide very little value. Usually Epics are used to describe products, releases or projects. They are high level stuff that are viewed by the management. Epics can be used to group things together, help finding work items and to monitor multiple project/releases. One thumb rule that I use is that Epic size in work hours is usually above 3 months. This is not exact rule, but gives some insight about how epic should be handled, if you have no idea how to wrap it.
Feature is a child of Epic. It is smaller and more easy to define. Feature is a set of features or changes that can be grouped under one topic. For example “Frontpage layout update” could be a feature, if it contains multiple steps to implement. Feature is a group of stories. “Add print button to top menu” could be a feature, if the implementation of printing is not yet done under any other feature. If the feature is just about adding the button and linking it into functionality, then it should not be a feature, it is a user story. Thumb rule here is that feature is typically from few weeks to few months of work for one full-time developer.
User Stories are children of features. They describe what the functionality should do. For example the print button user story could be something like:
“As a user I should be able to print the current page from top menu button”
And the description:
“Add new print button into top menu. Print button is visible for all users. When button is clicked, the Windows print dialog will appear and user can change printer settings from there, before printing the current page. Page must be fit into one page.”
Stories is the work item level, where manual testing should appear. They should have accurate description, so that anyone in the team can test it and verify it. Stories are the backbone of good backlog.
Task level is for developers. Developers splits the user stories into tasks and they use the tasks to track progress of completing user stories. Tasks describes the concrete steps to implement the story. For our print button we could add tasks like:
- Add new button into top menu
- Implement print functionality into product
- Link print functionality into new button
- Localize dialog and print button
- Add new “Printed” datetime field into database
Developers should create as many task as required to split work into reasonable size. Good task size is less than a day, so you should be able to finish the task within one full work day.
Bugs can be handled at user story or task level. Usually there is need for both, so the solution is to add new work item type for user story level bugs and use Azure DevOps bugs to track user story related bugs. The need for user story level bug is usually, that tester finds a bug that is not related to any existing user story, so creating user story for bug is just extra work. It is easier to create user story level bug directly.
Size of work items
I usually use the following table as an example of work item types. It is rough estimation, but gives one kind of view for different types. You should always reflect the work item sizes as the size of work you are working with. If you usually do small changes are consists from several steps, then the small change should be user story and steps are tasks.
| Work Item Type | Minimum size in days | Maximum size in days |
| Epic | ~90 (three months) | No limit |
| Feature | ~5 (work week) | ~90 (three months) |
| User Story | ~1 (work day) | ~14 (two weeks) |
| Task | No limit | ~1 (work day) |
Note
These are the ready build work item types, you can easily add own types and set their behavior by customizing the project process
Summary
Use different work item types to split the work and monitor progress of project at the different levels. Feature level is for top level management and user stories are for the project managers and product owners. Let developers handle the tasks and focus on writing good descriptions for user stories.