Transparent visibility
Every project has largely silent stakeholders who do not actively input into the project but do monitor its progress. These may be the stakeholders who finance the project or the may simply be senior management. By using Agile techniques you can get these people on board by providing them transparency and visibility.
Like it or not, visibility is one of the traits that Agile brings to the party. This visibility is a natural output of Agile process and forms an important part of the inspect and adapt feedback loop. You must be able to see what's going on so you can diagnose problems and make appropriate changes.
What you see of your project depends on what you measure; what you measure will be affected by the measuring. This is an important and related feedback cycle - setting metrics will shape project outcomes (I'll cover this in detail in my next post)
One of the metrics collected in Scrum is the estimated number of task hours remaining in the Sprint. We can use this information to create what is called a Burndown chart. A burndown chart is basically the team's remaining estimated time plotted against remaining time. The shape of this chart can help the Scrum master to see how well an iteration is going and to plan ahead for the coming iteration. To keep track of the software build as a whole a Release and Product Burndown can be used. This will track team output vs. time to release
The first step is in estimating tasks for users stories. User stories that have been chosen for a Sprint need to be unbundled into smaller actionable tasks. By doing this the team get a much clearer picture of the user story and tasks can then be estimated in 'man hours to complete'.
Estimates for each active task are updated by team members as they work their way through a Sprint. When a task is complete it is updated to show zero hours remaining. If a task is not completed by the end of that day it is re-estimated to reflect time remaining to complete it. This information is used to track the amount of work hours remaining in a given iteration; the Burndown chart.
This detailed level of time tracking can make some developers feel uncomfortable; they can feel that they are being monitored for efficiency like workers on a widget production line. When this happens team members may not update their hours on tasks and may slip into simply reporting a task is finished - some may not even do that!
Sprint Burndown charts become inaccurate and difficult to create when this happens. The teams ability to work together can be inhibited by this kind of scenario too. No one knows what's being worked on and the inevitable clashes begin. Luckily for us Boris Gloger and Tobias Mayer have come up with a simple and elegant solution.
During Sprint planning the team should not estimate the amount of time to complete a task, but simply ensure that each task is sufficiently small enough to be completed in a work day. By doing this a Burndown chart can still be produced and the team don't feel like they are being production line managed.
A by-product of this approach is that the team task board becomes much simpler and more effective. Every day during the 15 min Scrum meeting team members move their chosen tasks for the day into the In Progress column of the board and throughout the day those tasks are completed and moved to the appropriate column. This provides the transparency and team visibility that Agile promises and management demands.
Posted in Agile, Scrum | no comments | atom