Work Items

The work items are the different things that agile teams complete. There are nine different types of work item:

These work items are assigned to teams, which work on them within an iteration. Work items contain information about the work item, its risk and value, its approval status, who it is assigned to, and its assumptions, requirements, tests, implementation, dependencies, and issues.

Information about the work item should include a description, the type of work item that it is, and the number of points that it is worth. This information is important because it keeps track of what kind of work must be done, which is used to determine what kind of team is required. The number of points is used to assign the work item to an iteration, based on the team's velocity.

The risk and value section includes business value, technical value, risk reduction, and penalty. The business value is how important the work item is to users and sales, such as an interface. The technical value is how important the work item is to the program's functioning, such as a database. Risk reduction is how much more likely the program will be to succeed. Penalty is how much of a problem there will be if the work item is not completed. The business value, technical value, risk reduction, and penalty combine to create a priority for the work item. This value is divided by the number of points, which represents the amount of work done, to produce the rate of return (ROI) of the work item. The ROI represents how much value you get per point of work done. This section is important because it keeps track of how important the work item is to the project, and how soon it should be completed.

The approval status keeps track of the state of the work item. The work item could be proposed, approved, not started, in progress, done, on hold, abandoned, or rejected. Once the work item has been approved, the date should be recorded so that the business knows when work could begin. This prevents pressure from executives to finish a high-value work item that was only approved the day before. Keeping track of the status is important because it lets managers know when the work item can be started, and when there is a problem with it.

Who the work item is assigned to should include the portfolio, project, release, and iteration that the work item is part of. This information helps to locate the work item and determine when it should be completed by. The team and (if necessary) user responsible for completing the work item should also be recorded, so that they can be held accountable for the work item's status.

The work item's assumptions are the working assumptions made when sizing and costing things. They are important because, if the assumptions are different from the reality, it could affect the time to complete the work item, or the value of the work item.

The requirements are the things that the work item must contain in order to be considered complete; for example, the requirements for a desk may be that it has four legs, one at each corner, and a flat work surface suspended by the legs. The requirements are important because listing them creates consensus among employees and allows the team to know when the work item has been completed.

The tests are the sections of the program that need to be verified before the work item can be considered completed. The tests should specify what should be tried, and what the result should be. Continuing the previous example, you should test that the legs are securely attached to the table by wobbling it, and the result should be that the legs remain attached and the table does not wobble significantly. Listing tests to be run ensures that they are not forgotten, and that the program works properly.

Implementation of the work item is a list of what has and has not been done. It is important to keep track of this because it prevents two team members from doing the same work. Implementation also keeps track of what has been completed, making it easier to tell when the work item is complete.

Dependencies occur when the completion of a work item requires the prior completion of another work item. Dependencies should be listed so that the team knows what order things must be completed in. They also allow the team to know who they need to ask if the dependency has not been resolved by the time the iteration starts.

Issues are any problems that occur when the work item is being completed. They should mention the type of issue, how severe the issue was, and how it was resolved, among other things. This record is important because it notes that there was a problem, and records how it was resolved in case the problem reoccurs.

Work items that become too large can be broken down into smaller work items. These work items require the same information as the original work item, but should fit more easily into iterations. When a work item is completed, the release is closer to being done, and the value of the project has increased.