Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

ALM Practices Part 10: Work Item Tracking

DZone's Guide to

ALM Practices Part 10: Work Item Tracking

· DevOps Zone
Free Resource

The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.

What is it?

Using Team Foundation Server’s User Story, Task and Bug work item types as the central unit of work for all the activities done within a project.


Why would you do it?

  • Because it adds traceability between the functional requirements and the way these requirements have been realized on a technical level.
  • Because it introduces a common view of the project between developers and the business people.
  • Because it allows you to keep track of why certain code changes were made.
  • Because it creates an automatic link between the work items representing functional changes, bug fixes and other code changes and the automatic builds.
  • Because it reduces the chance of ending up with loose ends.


What’s the usual thing to do?

  • Track each and every activity that needs to be done in a project as a work item.
  • Use that work item as a central placeholder for all related communication, code changes, discussions, etc.


How do you do that?

  • Register all functional and non-functional requirements as User Story work items and all bugs as Bug work items.
  • Also include non-coding related activities such as deployment activities, writing documentation, assisting the marketing department and such. This improves the transparency of the work that is done in a project.
  • Break these down into one or more linked Task work items and use these for each and every source control check-in.
  • If you are faced with a research task which is difficult to estimate, consider using a Spike with a time-boxed amount of work.
  • Never check-in anything without associating it with a task.
  • Never check-in anything without providing a clear description describing the set of changes (as Check-In Comments).
  • Use Check-In Policies to require developers to provide the comment and the associated work item(s).
  • Rigorously file all loose ends and ‘things to do at some time’ as a Task, preferably linked to the associated Bug or User Story.
  • Consider adding a custom Storyotype field to the User Story work item type to differentiate between functional and non-functional requirements and to assist in scoping the User Stories.

The DevOps Zone is brought to you in partnership with Sonatype Nexus.  See how the Nexus platform infuses precise open source component intelligence into the DevOps pipeline early, everywhere, and at scale. Read how in this ebook

Topics:

Published at DZone with permission of Dennis Doomen, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}