Dominique Stender Good software is only the beginning…

Attempting Scrum in a SDLC environment, pt. 2

In the first part of this article series, I covered the aspects of the real life office environment. This included the lack of physical space for pinboards etc. Go check it out.

In this second part I will focus more on the virtual environment, the tools typically used by a company following the traditional waterfall approach / SDLC and how you might still be able to use these tools for Scrum.

Bug tracking system

Let me start with the bug tracking system. Most likely your organization will have one of those. Typically issues can be categorized, prioritized and assigned to a person as well as tagged or grouped into releases. To make this tool work for you in a more agile way you could create a couple of additional categories and put everything (!) into that system: Don't put only issues into it. Also add things like feature requests, enhancements, documentation, testing and refactoring tasks. I'm sure you can come up with more with a bit of thinking. Just be careful not to make this more complicated than required...

Well, that looks pretty much like a product backlog to me. You can do a printout of the overview and pin that to the board for better clarity. Stick it to the window with Scotch Tape if you don't have a pin board. In any case you should make this virtual backlog physical, otherwise the transparency will suffer. Only with a physical product backlog the team will have a clear idea about the big picture.

The overhead to maintain that printout would be minimal. You effectively avoid having two independent lists (in my experience always a recipe for disaster) and your not-so-agile management will probably be pleasantly surprised by the transparency you introduce.

Time tracking system

Next on my list is time tracking software. You know, that thing where you book how much time you spend on each project and / or task.

Well, there are two major ways to handle these in an agile way.

First, you (or the project manager) can create one bookable item in the tracking software for each of the tasks in the sprint. That'd mean one bookable item for each issue in the Bug tracking system (see above).

The benefit of this approach comes with reports - if that time tracking software allows custom reports based on Excel or similar, you can create a sprint burndown chart quite easily. Each item has a planned amount of effort (from Sprint planning) and the actual effort booked by all team members. That's all you need for a burndown. Calculate the sum of each and have Excel calculate a bar chart for each day - the sum of the planned efforts minus daily booked time is the sum of currently remaining efforts... at least until a task is re-evaluated. In this case you'd have to change your estimation.

The downside of this approach I'd say is efficiency. Depending on how userfriendy the interface is, tracking the time as a member of the agile team in a halfway precise manner can take quite a bit of time. Time better spent elsewhere. However, your company might demand such fine grained tracking. In that case it is best to get the most of it and get the burndown chart out of it as well.

The other way to handle this is on the other extreme of the bandwidth. Create one single task for the project and have all members of the team book all times onto that. They will love you. Higher management however may not, so use this with care. If you decide to go with this, you should encourage the team members to update the story cards with the current estimations, to keep track of where you are in the sprint and to generate the sprint burndown chart manually.

As always, the truth probably is somewhere in between. You could create one task for each type of work, i.e. one each for coding, testing, documentation, technical design, ... This will give much more clarity without too much overhead.

Conclusion

Your mileage may vary. The ideas presented here work for me, in the company I work, with the expectations that my management has. This may or may not hold true for you, and in your environment.

Let me know how you handle these situations! Use the comments!

Related Posts:

• Pen & paper Scrum – 10 days edition
• Scrum with pen & paper
• Ken Schwaber’s “Confusion about Scrum”
• Attempting Scrum in a SDLC environment, pt. 1
• Good summary of Agile misconceptions