Project Management with Azure DevOps: Work items in the Agile process

In this blog post I would like to introduce and briefly describe the work items used in the agile process except Bugs and Issues. The process is fully customizable as I did to add the “Blocked Reason” section in the User Stories.

What is a User Story?

The user story is a simple, short description and provides an overview of a task which a team member must do in the sprint. The User Story is created by the Team or product owner.

Ideally, good user stories should follow the model INVEST:

• “I” ndependent — Independent of other user stories “
• “N” egotiable — There must be conversations between client and development team, flexibility, not a closed contract
• “V” aluable — Each user story must add value to the product
• “E” stimable — Each user story must be able to be expressed, in a reasonably approximate way, by the development team — but in time, in complexity in relation to the others (story points)
• “S” mall — Each user story, ideally, must fit in one iteration (sprint). If it does not, it is strongly suggested to break it down into parts.
• “T” estable — Each user history must be able to be validated.

1: Title of the User story must be descriptive about the work that is to perform and consist of the information AS <role> I WANT <objective> FOR <motivation>

2: Each user story is assigned to one main responsible person. The underlining tasks can be assigned to more than one user

3: A tag defines some additional information e.g. for billing or which team works on the topic

4: The description provides more detailed context for the user story. It contains the following elements.

• Context: Provide application and use context to the developer and user, to improve the understanding of the user story title.
• Links to the Mockups or design: They are a great help to understand how the functionality in the user story is to be mapped in the application.
• Constraints: Things that all the actors involved in the user story must consider (navigation constraints, design constraints, use cases or business flow cases).

5: Discussion field. Here comments can be made. With the @PERSON reference it is possible to notify other team member about issues, blockers or spread information

6: The Story points

7: Priority of the story assigned from the PO 1-high, 2-medium, 3-low, 4-very low

8: Risk in high, medium, low to define if the story has a critical impact on the business

9: Link to sub tasks or other corresponding user stories. Most important:

• Related
• Parent
• Predecessor
• Successor

10: Blocked Reason (Why is a user story blocked and how can it be resolved). Also, a tag is to set if the story is blocked (not in standard template)

11: The acceptance criteria define the conditions which must be fulfilled that a story can be considered as closed. They should follow criteria

• ATOMICITY: They must have 2 unique results: SUCCESS or FAILURE (there is no term “partial success” — an acceptance criterion must always give us a GREEN or RED)
• NON-AMBIGUOUS: They must be interpreted in only one way by N people
• VERIFIABLE: They must be written so that they are quickly verifiable by the client
• COMPLETE: The set of acceptance criteria should include all functionality requirements

e.g. “The username MUST have value, otherwise a relevant error message will be displayed “

12: State of the Story

• New — in backlog or fresh assigned
• Active — Work is started
• Resolved — Work is done
• Closed — User Epic is finished (Only if PO gives the ok and only set in review)
• Removed — The Work Item is not completely deleted (can be queried)

13: Area path for the story (defines the Team and the company who works on the item)

14: Iteration path defines the Sprint to which the story is assigned

A quick digression on Story Points

„Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. “

Each story gets assigned a relative value. The values refer to numbers derived from the start of the Fibonacci sequence with little difference, where each value is the sum of the addition of the two values before. We use the values 1, 2, 3, 5, 8, 13, 20, 40, 100

It is to state that a user story should not use an estimate bigger than 13 for our purpose because otherwise it can and should be cut in increment stories.

The value resembles the combination of the following metrics

• Complexity of the tasks for the story (Efforts needed to develop the feature)
• The number of tasks and repetition (amount of work)
• The risk and uncertainty (e.g. for trying out new technology, dependencies, unclear demands)

A User story of 3 should have 3 times the work as a story with 1

A Task is the child of a Story

A task is a work item which is maintained and create from the developer who works on a User Story.

1: Title of the Task

2: Each user story is assigned to one main responsible person. The underlining tasks can be assigned to more than one user

3: A tag defines some additional information e.g. for billing or which team works on the topic

4: State of the Task

5: Area path for the story (defines the Team and the company who works on the item)

6: Iteration path defines the Sprint to which the story is assigned (same as mother user story)

7: Estimate in hours of how long the work is going to take

8: “Real” time in hours the work has taken

9: Discussion field. Here comments can be made. With the @PERSON reference it is possible to notify other team member about issues, blockers or spread information

10: The description provides more detailed context for the user story. It contains the following elements.

11: Link to sub tasks or other corresponding user stories. Most important:

• Related
• Parent
• Predecessor
• Successor

12: Priority of the story assigned from the Developer 1-high, 2-medium, 3-low, 4-very low

A Feature is a Container or Parent which contains different Stories

A feature typically represents a shippable component of software. An epic represents a business initiative to be accomplished. Here are a few examples of each.

1: Title of the Feature

2: Each user story is assigned to one main responsible person. The underlining tasks can be assigned to more than one user

3: A tag defines some additional information e.g. for billing or which team works on the topic

4: The description provides more detailed context for the the Feature

5: Area path for the story (defines the Team and the company who works on the item)

6: Iteration path defines the Sprint to which the story is assigned

7: Priority of the story assigned from the PO 1-high, 2-medium, 3-low, 4-very low

8: Risk in high, medium, low to define if the story has a critical impact on the business

9: Effort means the time budget for the epic

10: Start and End-Date of the implementation of the epic

11: Discussion field. Here comments can be made. With the @PERSON reference it is possible to notify other team member about issues, blockers or spread information

12: State of the Feature

• New — in backlog or fresh assigned
• Active — Work is started
• Resolved — Work is done
• Closed — User Epic is finished (Only if PO gives the ok and only set in review)
• Removed — The Work Item is not completely deleted (can be queried)

13: Link to sub tasks or other corresponding user stories. Most important:

• Related
• Parent
• Predecessor
• Successor

The Epic the Parent above all

A Epic contains normally one or more features

1: Title of the Epic

2: Each user story is assigned to one main responsible person. The underlining tasks can be assigned to more than one user

3: A tag defines some additional information e.g. for billing or which team works on the topic

4: The description provides more detailed context for the the Epic

5: Area path for the story (defines the Team and the company who works on the item)

6: Iteration path defines the Sprint to which the story is assigned

7: Priority of the story assigned from the PO 1-high, 2-medium, 3-low, 4-very low

8: Risk in high, medium, low to define if the story has a critical impact on the business

9: Effort means the time budget for the epic

10: Start and End-Date of the implementation of the epic

11: Discussion field. Here comments can be made. With the @PERSON reference it is possible to notify other team member about issues, blockers or spread information

12: State of the Epic

• New — in backlog or fresh assigned
• Active — Work is started
• Resolved — Work is done
• Closed — User Epic is finished (Only if PO gives the ok and only set in review)
• Removed — The Work Item is not completely deleted (can be queried)

13: Link to sub tasks or other corresponding user stories. Most important:

• Related
• Parent
• Predecessor
• Successor