Using the daily stand-up to ensure burndowns are accurate – Perficient Business Process Excellence Blog
Perficient Business Process Excellence Blog Blog

Using the daily stand-up to ensure burndowns are accurate

Confession time: I used to be a developer. And when I was a developer one of my least favorite moments was when my project manager would interrupt me to ask for status. My reasoning was something along the lines of: Hey, I’m actually *producing* something here. Can you leave me alone so I can get this done?

But now I’m a project manager. In addition to being personally responsible for the schedule, I also sit in the meetings where I see directors try to defend their budgets – the budgets that pay for the developers. And I know that, much as developers might wish for it, in the real world no one just writes a blank check for their dev team. They want to know what the team is working on at a good level of detail, and they want a realistic sense for how quickly they can finish things.

Agile, really, is all about balancing these forces. How can you generate realistic estimates, reduce the cost of change, and stay out of the developers’ way – thus keeping them productive? In my experience, the key is making sure the developers track their individual tasks in some system of record every day. That same system of record needs to hold the backlog as well, so things can move easily between backlog, in progress, and closed. For me, the most convenient mechanism for tracking all this is Team Foundation Server. (I’ve also used JIRA, but TFS is my favorite for reasons I’ll discuss below.)

So I’m clearly a believer in this, but then again, I benefit from it – in the form of being able to track trustworthy burndown and backlog statistics quickly and easily. The developers … that’s a harder sell. You can give them the speech about protecting budgets and estimating velocity, and they may listen. But there’s still a chance you’ll end up with team members who are not good about maintaining their audit trail. If that’s the case, here are a couple of tricks that I use to keep everyone honest.

  1. If you’re not already doing this, ask the team to track all work on the iteration in the form of TFS tasks, which can be associated with either user stories/features or bugs.
  2. While we’re at it, ask the developers to also track their actuals within these TFS items, every single day. (For consultants, I would argue they should be doing this and their billable timesheet every day regardless.)
  3. Schedule TFS burndown reports to run about an hour before daily standup, and send them just to yourself. You can open those reports as you get your notes ready and easily see who forgot to enter hours the night before. You walk into standup with this knowledge in hand.Here’s an example of a burndown where the devs have pretty clearly fallen behind on their actuals entries:BurndownExample
  4. Reinforce the importance of entering tracking items for all work by asking for TFS item numbers during daily standup. I will usually pull up a TFS query of everything slated for inclusion in the iteration, and then if I don’t clearly understand which item the developer’s update relates to, I’ll confirm during the call.
  5. Build updates to the system of record right into the standup. If you have a team member whose actuals are clearly not in, or who did not have a TFS item for their work, ask them to rectify the issues in real time.
  6. Send out daily stand-up notes within an hour of standup completion each day. In these notes embed links to all in-process items, easily generated from the web client version of TFS, right in line with reported activity against those items.
    Team Member Tuesday Today Issues
    Pooja (QA) [Weds] .300 testing currently at 40% complete. (Test plan.) [Thurs] .300 testing continues, on plan for certification date.  
    Imran (dev lead) Checked in code for logging errors (26434). Updated deployment documentation for .300 (26305). Moved on to session storage bug 26248. Conversations with Tim. Closing out session storage bug 26248. Moving on to image updates (26118) if time allows.  
    Tim (dev) Closed out updated automation routines (24591). Worked on two e-mail notification bugs, which required some conversation with Imran. (26356, 26362). Continuing with notification bugs (26356, 26362), hoping to finish today.  
    Shannon (product manager) No tasks. Confirming outage window for proposed release date. Review of deploy documentation (26305).  
    Jen (project manager) Checking in on schedules for next week. Weekly reporting.  

    I like to attach a burndown report too. You may have to rerun burndown if you’ve chased anyone to put in their missing actuals during standup.

You can imagine how this plays out during the standup. I often end the meeting by pinning down the developers who either didn’t have their actuals updated, or didn’t have their work items in TFS. After a while the tech team gets used to this behavior. These days as I go around the circle receiving updates and taking notes, I’m often also getting Lync messages from developers confirming TFS updates, so they can avoid being held late.

While this approach is not necessarily TFS-specific, when I employed it using JIRA I found the admin burden higher. I personally found the JIRA burndown charts were not as helpful, and I could not get PDFs to my inbox from JIRA the way I can with TFS. Also, TFS’s very easy dump to Outlook feature let me generate web-friendly links for inclusion in my notes quickly. Finally, my PM counterpart at the client had some folks on her end who were new to Agile. They still asked her to report status via Project files with percents complete in place. Using TFS we were able to generate those reports very easily – but that’s a topic for another post on another day.

Leave a Reply

Your email address will not be published.