A Backlog for Improvements

During a training session that I conducted last week, a very interesting question popped-up, how teams accounts in their improvements after Sprint Retrospectives?

What I use for my teams is a very simple technique: I take pictures of all problem insights and improvements that we''ll be tackling in the next Sprint after the retrospective. I then post those pictures in team's SharePoint and I project them in the initial part of the next retrospective meeting in order to have a feel of what has been accomplished and what not.

This works quiet well but we still miss the feeling of progress, more to the point, we're lacking the psychological effect of burning something (like hours, story point, user stories or any other indicator).

What I propose is to create a backlog of potential improvements, we could go as down as estimating effort and time and maybe creating associated tasks, but my initial feeling is that this would over complicate things. Instead the attack plan should be just logging in this backlog the list of potential improvements from the Sprint Retrospective, prioritize them and then work in the top priority areas for improvement. No much data about how improvements have been accomplished should be logged, unless somebody in the team wants to document them as case studies.

I'll be trying to implement this idea and write later with actual evidence in hand.

Jazz Band Conductor a.k.a. Agile Project Manager

I though in a interesting analogy the other day, if you hear a jazz band (and hopefully a good one) you'd realize that the conductor encourages improvisation. Actually, improvisation is a distinctive characteristic of jazz music.


The conductor is someone that is deeply familiar with the instruments and music, but not necessarily plays with the band. What is important for him is that everybody plays good jazz and the audience gets satisfied. Making every musician in the band happy is of course a priority, happy people are generally more willing to improvise.

There's of course an style to follow and a lot of training, all these required for being able to improvise in the first place. But the goal is always at sight, have fun and play good jazz. Again, the conductor don't tell the team what to do, he let the team create and help it to reach the next level. This is certainly a lesson that we can translate for Agile Project Managers.


On the opposite side, this guy has everything figure out from beginning to end-or at least he likes to think so-, everybody in the chorus has to sing exactly what has been rehearsed endless times.

No deviations from the score are allowed, improvisation is not specially highly rewarded. Do you see any similarities with traditional Project Management?

The Most Important Meeting in Scrum

I was thinking on which would be the most important meeting in Scrum, this questions crossed my mind because I've heard that many teams in my organization still believes that Scrum is all about the Daily Scrum Meeting. Maybe the confusion came from the fact that both Scrum-the framework- and Scrum-the meeting- has the word "Scrum" in their names. Whatever it was it's pretty obvious that is a serious mistake that needs to be corrected.

An interested behavior that I've observed on those teams is that they believe that they're doing Scrum just because they have a daily stand-up meeting. Nothing could be further from the true spirit of Scrum.

But going back to the initial question, in Scrum we have meetings like:

• Planning Meeting
• Daily Scrum Meeting
• Sprint Retrospective Meeting (a.k.a. Post Morten meeting)
• Mid-Sprint Review Meeting
• Release Retrospective Meeting

This list is not definitive and surely enough more meetings will be added/suppressed by teams based on their specific needs. However, the meeting that in my humble opinion is the most important in Scrum is the Sprint Retrospective Meeting. Why? Because this is the meeting for revision and improvement and Scrum is all about inspection & adaption.

The Old McKnight Was Right

William McKnight at 3M create a new mentality: let the workers innovate. This revolutionary mentality made of 3M a company capable of being always surfing the wave by introducing dozens of new products to the market and create very diverse business units.

I read a very interesting quote from McKnight:

"Hire good people, and leave them alone."
"If you put fences around people, you get sheep. Give people the room they need."
"Encourage, don't nitpick. Let people run with an idea."
"Give it a try—and quick!"

This is something that definitely goes inline with empowering the team and other core Scrum values . Again, I'd recommend that we listen to old McKnight.

Technical Debt a.k.a. Torpedo in the Water

What can be more dangerous than having a armed torpedo coming fully ahead to your ship? Short answer: not knowing that the torpedo is coming and just feel the blast and have only an split second to realize that you, your ship and your crew are domed.

You could mitigate this by having some good active and passive radars that at least tell you that at torpedo is on seeking mode and looking for your ship. Of course knowing what is coming is times better than being taken by surprise.



During the Sprint we have a very good indicator-you can call it information radiator if you want-for knowing than something really bad is coming. This indicator is the technical debt which in its simplest definition is just unfinished work. But let me elaborate on this definition a little more, technical debt is:

1. Schedule work that has not been even started
2. Schedule work that has not been implemented
3. Implemented work that has not been tested
4. Tested code that failed to pass all test, bugs were encountered
5. Work with bugs for which fixes were provided but rejected
6. Retest work that is still in progress, consequently there's still uncertain that fixes actually work
7. Unplanned work that has been discovered in the Sprint but that has not been completed-maybe not even started
8. And the worst of all, undiscovered work that has not been considered but that will be necessary-armed and locked torpedo

Technical debt, like torpedoes, is lethal unless you know that it exist and is coming towards you. If you detect a torpedo in the water, you can still save your ship-and your life of course-if you launch counter-measures. The sooner you act, the more chances that you have to save your boat, sounds similar to technical debt?

Agile Flavors

Thinking tools: Tools that we use in our field of expertise to build software. In other domains they’re also called mindsets or philosophies. Some examples are:

• Lean
• Agile
• Systems Thinking
• Theory of Constrains

When thinking becomes acting you need a toolkit (some people like to call it framework). There are many toolkits/frameworks out there to put Agile/Lean at work:

• Scrum
• eXtreme Programming
• Kanban
• RUP

Some thoughts on the various disciplines:

• Agile: A core set values for executing projects
• Lean: A core set of principles for running a company
• Scrum: A set of agile management practices based on one principle: Inspect and Adapt
• XP: A set of agile software engineering practices/processes

Building a Burndown Chart using Story Cards

This is something that I tried the other day on a training session. I divided the class in three groups of seven to eight participants, each group created a template for its user stories cards.

I specially like this template because it has all the necessary information in just one place, it has fields like:

1. Developer's initials
2. Quality Engineer (QE) initials
3. User story name
4. Developer's estimated time
5. QE's estimated time
6. Developer's actual time
7. QE's actual time

By adding developer's plus QE's estimated times, one can have the total estimated time for the user story. If one does this for all user stories, one will ending up having the total schedule time for the Sprint.
This time would be the total allocated time or time that the team has to burn during the Sprint. In the chart below we had check point every five minutes (because our simulated Sprint only lasted 15 minutes) to see how much has been worked and what is still remaining. This information is what allow all three team to draw burndown charts and use them as a tool for monitoring progress and forecast Sprint degree of completion -only from a time perspective.