Tracking frequency
In agile sprint tracking, at an established tracking schedule, team members will enter tracking information on the tasks they are currently working on. Teams may choose to do this daily, weekly, twice a week, or at whatever interval best serves their information needs. Entering tracking information daily ensures that 1) information is entered while fresh on people’s minds and 2) project charts and graphs will be updated. Many teams will track once or twice a week until the last week of the iteration, and then make sure information is provided more frequently to ensure daily visibility across the iteration. Much of this information should also be communicated during the daily stand-up meeting. Reviewing a tracking graph should be expected to replace the valuable communication of the daily stand-up meeting.
Feature vs. task completion
When all tasks for a feature are completed, then the feature is considered complete. Some teams may include the requirement of all acceptance tests passing as well.
FAQs
Why track an iteration?
For extremely short iterations, such as one week, the need to measure interim status diminishes, but even within a one-week iteration, it is valuable to understand whether the work is halfway complete mid-way through the iteration, as well as potentially how much additional work has been added to the iteration since the initial iteration plan. As iterations increase in length, the need to understand accurate status increases.
What information is tracked during an iteration?
Very little information needs to be tracked during an iteration. For each task, the effort expended and remaining work estimate should be tracked regularly. The status of acceptance tests should also be tracked. Scrum ignores expended effort to focus sprint tracking solely on remaining work estimates.
Who enters tracking information?
Typically, each individual will enter their own tracking information. Some teams elect to designate a single individual each iteration to collect and update all tracking data for the team.
How often do team members enter time?
Each organization will establish its own tracking schedule. Teams typically range from every day to every week with longer iterations.
Should estimates be changed during an iteration?
Estimates are just that – estimates. Some tasks will be completed early, some late, and new tasks will generally be identified. Ongoing consistency and reliability is the goal as opposed to estimation accuracy. If a team consistently delivers 20 ideal days worth of features every iteration which generally results in a task estimation of ranging between 200-220 hours, then this is plenty of information to accurately plan and manage a project. This may result in 260 hours of actual work each iteration if this is being tracked. So the need to go back and revise estimates is not necessary in light of using historically validated estimates for planning as opposed to actuals or projected capacity.
What if the remaining effort exceeds a task’s original estimate?
If this is the truth, then this is what is entered. This is simply a reality on some tasks and the goal is to represent reality with tracking information, not some ideal or calculation.
Why doesn’t remaining effort just get calculated?
Calculated numbers do not represent the true state of a task or project, they represent a mathematical calculation that historically has proven unreliable and inaccurate. In order to accurately convey status on a task, team members should always consider what remains based on all the information now available.
How do you know when a task is done?
A task is done when there is no work left to be done by anyone on the task.
How do you know when a feature is done?
A feature is done when there is absolutely no work left to be done on the feature, and the feature has been accepted by the customer.
At the end of an iteration, what if a feature is only partially done?
If a feature is partially complete, it is up to the customer to determine whether the feature should be split, moved to the next iteration, reprioritized, etc. Agile development is generally considered very binary in that value is either delivered or it is not. If work is done, but no business value is delivered, then agile considers this a big goose egg. If the feature can be split, with some value being delivered during the current iteration and some later, then this is up to the customer and team to decide.
