The first of these tasks was an ongoing piece of software custom-written for a single user. It has been completed long ago, but we had a task about possible changes needed to be made, and indeed, on the final day of sprint, the user provided the requirements. To me, this goes against Scrum principles, and as such not only makes me angry, but makes me wonder how well we’ve actually implemented scrum.

The second incomplete task was never started, it required a deployment to be made first. I had personally planned the deployment for the final day of sprint, and even informed users, but this was canceled by our director, who essentially was in a panicky mood, and I feel there was no real reason not to deploy.

That leads to the final unfinished task. Deployment. We set aside eight sprint hours for the deployment of the product onto the production environment, and today, the retrospective and demonstration day, is when we’ll have to do it.

Nevertheless, this sprint went well. A word of warning I could give as a result of my experiences is – if you have an easily startled director overseeing what you do, sit him/her down with a cup of hot chocolate and let them experience a comfy sofa while you go behind their back create mad product downtime. Or get approval beforehand.

They were ordered by our senior engineer, who is also a partner in the company, and their arrival was a surprise to me. Unfortunately he went a bit overboard when ordering.. considering that there’s enough cards in a deck for four developers to use, he’s ordered us enough for a hundred and twenty people.

I put it down to sheer old-fashioned optimism. If pressed we could line up about twenty people with a ‘developer’ label on them, if we scoured every office in our company and stuck a few mannequins between them.

So I am illegally going to give a few packets away to readers of the blog. Contact me on Skype (jacob.ozolins) if you are interested (I’ll edit this post to remove this sentence when there’s none left).

You can order your own too, if you want: http://store.mountaingoatsoftware.com/products/planning-poker-cards

Each deck contains enough cards for four estimators to each hold cards with the following values: ?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and ∞. The cards are printed on the finest quality card stock available. Each deck comes in a box to help keep the cards from being damaged.

We’ve been using laser printed pieces of paper in the past, which are now frayed and yellowing. These cards make the developer feel at least a little more ’serious’…

Towards the end of almost every sprint, we were seeing that our burndown chart suddenly drops down as tasks are put through testing.

Due to this, we don’t really get an idea of where we are, in terms of development. An eight hour task could be coded but not tested, and that means eight hours still in the backlog. Spending twenty minutes testing it essentially ‘leaps’ the task from zero to completion. Not correct at all.

One solution is to report hours spent on all tasks, rather than just completed tasks. This might be even further from reality – essentially it would just show effort, which is generally not going to change from day-to-day and reporting it doesn’t show anybody anything.

This was causing me to have a minor meltdown, and thus this rather colourful chart evolved in my Excel spreadsheet:

The sprint meltdown chart.

Forgive me for the lack of labels here. Y-axis is number of hours (points) remaining in the sprint. X-axis is the nth day of the sprint.

The meltdown chart is always displayed as an ‘X’, with expected effort starting at zero and moving up to the planned hours limit, and expected burndown moving in the opposite direction.

Additionally, there is a central ‘window’ in the chart, and using this window I can spot mid-sprint what the outcome of the sprint will be if we maintain current progress.

There are four sections of the window, and briefly, if the real effort and burndown intersect in pane:

• 1. Effort needs to be reevaluated. Developers are sprinting and can probably cool off a bit, depending on whether burn is above or below average. If above, then tasks estimations are askew. In this case I would spend time to reevaluate with the team. If burn is below average, the sprint might have room for additional tasks. I would ask the developers if they would accept extra work added mid-sprint. Keep in mind that doing this might break the sprint later on.
• 2. Sprint is in serious trouble. If actual effort is below expected effort, it’s time to take the cane to the developers. In reality this can take the form of discussing the problems after a stand-up meeting, or scheduling a brief meeting. It’s likely the developers will state that they incorrectly estimated the tasks, and will complain that external factors are changing the scope. It could be time to alter the backlog, removing items if necessary.
• 3. Sprint estimated poorly, or horrible code quality. If the burn is in this window pane, then the second half of the sprint will be a walk in the park. You can decide if you want developers to stroll or pick up additional tasks. It might be worth paying closer attention to the quality of code – unless estimations were completely off, one or more developers could be writing rubbish code. I would spend time investigating the overall quality of the work done on the tasks.
• 4. Increase effort, depending on the burn, if it is above expected. If it’s below, effort can remain the same. Sprint is more or less on target.

These points depend mainly on how close the intersection is to the center of the chart. The closer to the center, the less attention you as a product owner need to pay.

In the image example, you can see our intersection landed in pane 2. From there, we turned up the effort of the developers, pumped them full of coffee, and managed to drag the sprint back on target.

I have no reservations when it comes to encouraging developers to work harder, but I see such effort boosts in terms of karma. More coffee mid sprint can more-or-less be translated into more beer at the end of it.