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.

About Story Points

Story points are a good estimation technique that you can use when you try to estimate complexity in user stories. Unfortunately, complexity is not directly correlated to effort and time so you might end up having ultra complex features that can be implemented by a very inspired developer in a very short time (yes, miracles can happen from time to time).

On the other hand, you can have low complex features that require many hours of repetitive work.

Another variable in the equation is the QE time that you'll have to commit to test the feature. Again, there's no direct correlation between the implementation and testing complexity. For instance, automated testing can save a lot of man hours and make testing easier for a highly costing -from development perspective- feature.

A guess the caveat here is not try to use story points as what they are not: a metric for progress and effort.

The Myth of the Accusatory Taskboard

I've seen many teams in many projects that are afraid of updating their real status in a taskboard because they feel that if they say the truth their manager will punish them. Childish as this might sound, this situation is not uncommon and frequently leads taskboards to be an inaccurate representation of the reality.

Let's start one step back, what is a taskboard in the first place? My answer would be this: a taskboard is a collaborative tool that the whole team uses to communicate ideas and reflect tasks status.

Conversely, what a taskboard is not is a reporting dashboard that upper managers look for finding problems and bottlenecks. Further, managers can't pretend to use taskboards for micromanagement and problem diagnosis.

Two steps back, Scrum is all about empowering the team, not about managers using reporting tools to controlling things in a project.

A Foreman has no Place in Scrum

I remember reading that Henry Ford T-model success came from the fact that the assembly line that he invented was able to produce 17 million of cars in less than two decades.

I also remember reading that his Detroit assembly plant hired employees from several different nationalities and around 50 different languages were spoken in the plant -something similar to the world software industry today. What make possible that all these people can work productively was Frederick Taylor invention: scientific management.

Scientific management is based on the principle that engineers -or foremen- study a process, optimized, and then teach workers how to do it. Deviations from the process are not allowed and creativity is limited at minimum. Quality is controlled on the base of how well workers sticked to the process and produced the expected results. Mechanization and mass production is the result of this management technique. Controlling and supervision is assigned to foremen that are appointed responsible from a group of workers and a portion of the production line.

This worked pretty fine for some decades until Japanese Toyota Production System changed the auto car industry forever. For starters this brought the idea of suppressing foreman and empowering teams.

It still strike me odd when somebody ask me about the best way to manage developers, Scrum principles are not about better management or better application of the scientific management. On the contrary, Scrum is about flat structures -no foremen- and creative thinking.

Metrics are not Crystal Balls

Teams need visibility of their progress, but how can they get enough visibility about how they are doing in the Sprint?


There's no short answer but you can try this:

1. Convince your team to believe in metrics.
2. Choose the metrics that best work for your project -simplest one is number of completed user stories .
3. Make everybody look at the same set of metrics.
4. Put all metrics in just one place (a taskboard and burndown charts are more than probably you'll need).
5. Create the habit for all your team to provide initial estimates and then compare them to their actual work.
6. Do not waste too many cycles trying to innovate in metrics, everything has been already discovered, is just matter or look what would be good for your project.
7. Metrics are not black and white, there's a lot of gray areas in them.
8. Metrics are indicators, symptoms but not conclusions or explanations.

What the PO Does During the Sprint?

Somebody asked me an interesting question: what does a Product Owner do during the Sprint? But before answering this question, let’s go one step back and see what the PO does for the release backlog.

Let’s start by saying that the PO has changing roles and responsibilities during the project. For instance, during the very inception of the project, the PO would be responsible for gathering the initial set of requirements–provided by the client–and together with the team, create an initial set of user stories.

This initial set of user stories is prioritized and estimated–using Planning Poker, T-shirt sizes or any other technique–by the team and the PO. This prioritized list of user stories is what accounts for the initial backlog or release backlog. One caveat, estimations provided in this stage are related to complexity, not to time or effort.

Building the Sprint Backlog

The sprint backlog should be a subset of the product backlog that the PO and the team agree to be worked during a time-boxed period of time: Sprint.

During the planning stage of the Sprint, the PO in collaboration with the Scrum Master are responsible for guiding the team in providing time estimates for the committed user stories. Over-commitment is hard to avoid in the first sprints because the team isn’t aware of its own velocity.

Based on the time estimates provided for each user story, the PO can calculate–adding up all the user stories times–the total number of hours that the team would be working on the Sprint. This number of hours is the total capacity allocated or hours to be burned during the Sprint. Making sure that these hours are burnt–and the associated user stories delivered–would be one of the key responsibilities of the team during the Sprint.

Running the Sprint

Scrum recommendations limit to say that the PO has to be available for the team during the planning stage and also during the Sprint, in case the team has additional questions. The PO also has to prioritize and reprioritize the backlog on a need basis. But it would seem that doing all this wouldn’t take much time, at least not to keep him fully busy during a three-week Sprint. This is one of the Scrum myths that I'll try to demystify.

So, let me bring some light to what the PO should be doing to stay entertained during the Sprint:

1. The PO should be in contact with the client showing and discussing results from the past demo. Showing something to a client just one time is usually not enough to have an accurate perception of what he liked or not from the product.
2. Clients are not always available for the PO, so chasing clients will consume cycles from the PO.
3. If the PO is working with a product targeted for multiple clients, the chasing/demoing activity increases exponentially consuming even more time.
4. Demoing a product without the team's assistance implies that the PO has to set his own environments and learn the product well enough and not only from a user's perspective. This is not a people's activity; it is more technical and will consume many cycles from the PO.
5. By using the product in his own environment, the PO will be discovering what I'd call "requirement issues". In fact, the PO will be doing "requirements testing" which is a validation of the product from a client’s perspective. Passing this test would guaranty that the PO has something he can sell.
6. Studying the market and monitoring competitors should also be in the PO’s agenda.
7. Defining new requirements based on client's feedbacks and market reading.
8. Adding new user stories into the project backlog by his own initiative and/or per team’s requests is pretty obvious, what is not so obvious is that the PO needs to ask the team to do some planning poker to estimate complexity for the recently added user stories and that the backlog would need to be reprioritized.
9. Grooming the backlog to accommodate new and changing requirements should be the tangible output from the PO's work during the Sprint.
10. Building and monitoring a burndown chart is also crucial for POs. Actually, the burndown chart should be used by the PO to see if the allocated hours are being burned at an acceptable rate that can be used to predict that all scheduled work would be completed on time.
11. Frequently enough, the burndown chart will show that the team is more likely to miss the mark, in these situations, the PO has the responsibility to negotiate whatever can still be completed on time. Having a bunch of user stories in progress is not as good as having a few completed–walking skeleton principle–.

As you can see, the PO has enough–and maybe more than enough–to keep him busy during the Sprint. One note thought, Scrum doesn't prescribe that the PO's tasks should be planned and tracked on a separate backlog, but what if some PO decides to do so? I'd be happy to hear about the results of this experiment.

The Real Kaizen Behind Scrum

My aikido sensei told me the other day "you need more kaizen, your aikido is not flowing smoothly". I thought to myself, "is my sensei referring to the same kaizen principle that we use in Scrum?".

So, after the class I sat with my sensei and I asked, "what do you oh sensei understand for kaizen?" This is what he responded:

"Kaizen in about seeing yourself and recognizing that you still have still much to improve and learn.

Kaizen is not about beating others, it's about learning and teaching others and together improve.

Kaizen is about being humble and be ready to recognize that your learning path just started and will never really end."

Much of this can be applied to Scrum, don't you think?

Applying Queuing Theory to Sprints

Queuing theory is one of those subjects that you learn in college but you never completely understand, like calculus or algebra. The problem with it is the little practical use you make of it.

I realized some time ago, that Quality Engineers (QEs) in my projects were not doing much during the first half of the Sprints and this had a recurrent pattern; they created test cases, preparing testing environments, updated existing ones, did some research, wrote training documents, etc. That sounds kind of ok, but the problem was that by the end of the iteration, they were all of a sudden overwhelmed by the amount of user stories they had to test. Consequently, they had to work killing hours (including weekends) to get the work done.

I remember that time ago, banks had a similar problem, tellers where not doing much during most of the day, but at peak hours they could hardly breathe because they would have a bunch of impatient clients formed on a line in from of them. Banks played smart and did something to improve their service systems and evenly distribute arrivals. Queuing theory-wise, if you can't increment servers, go in the other direction and look for a stable arrival rate.

It's pretty obvious that we have a lesson to learn from banks and other service industries. So what can we do in order to help balancing Quality Engineer's work? Some ideas below:

1. Plan for micro-deliveries, small pieces of functionality should be passed from development to quality assurance on a daily basis, if possible.
2. Don't pass code that is not on a build for testing, builds are great for version control and integration testing.
3. Automate as you implement, run Build Verification Test on a daily basis.
4. Write test cases as you progress with testing; don't wait to have tons of test cases written before starting to test.
5. Sync developers and QEs’ efforts to know what to implement and test.
6. Don't plan for large user stories, break them into smaller chunks of functionality–use the INVEST principle.
7. The acceptance criteria is not fixed, it evolves as the functionality is implemented and tested–it certainly exists from the beginning but should be refined as we move into the sprint.
8. Look for people that are sitting idle because they're waiting for something to test, waiting is waste and has to be eliminated.

The ultimate goal should be to have a stable flow of code from development to quality assurance and vice versa. A stable flow is what will allow you to make better use of your QEs reducing queues’ length and decreasing throughput time for user stories.

The Rule of No Rules

Is Scrum all about anarchy? Well, yes and no.

Yes, because Scrum is not about forcing rules and creating enforcers of this rules. There's no hierarchy and authority representatives, no one is entitled in a controlling role.

One common misunderstanding is believing that the Scrum Master is like a police officer that has to make team member follow the rules of the "true Scrum".

No, because Scrum has values and principles that one should understand and follow. Working agreements reach consensus in the team and are applied on discretion. The team auto manages itself and decides what to do and how to do it.

Scrum is all about negotiation, inspection and adaption. No imposing something and making it work by force.

Telling the Tale Using a Task board

What a taskboard is?

• A communication vehicle
• A wall or a whiteboard where the team post their kanban cards
• A visual indicator -a.k.a. information radiator- that provides a quick status check

Who should build it?

• The Product Owner should build the first version
• The team can increment it's content in each Sprint

Who should maintain it?

• The main responsible is the Product Owner
• But this doesn't excludes the team in participating
• The ultimate goal is that the taskboard accourately reflex tasks -kanbans- progress
• The rule of thumb is having always updated status of tasks completion

Who should prioritize it?

• In kanban the taskboard is not prioritized but in Scrum it is, so the main responsible for this is the Product Owner

Does it has to be online?

• Yes, if you want to save the kanbans for later analysis
• Yes, if your team is distributed
• Yes, if you have way to many kanbans to put in a single wall (smells: problem indicator)
• Yes, if you have found an electronic taskboard that is not complicated to use and fill your needs
• Otherwise you should be using the old and simplified version: post-its and a whiteboard

Management by Sight

To world famous Toyota Way, based on the Toyota Production System success, has a very interesting concept that always caught my attention: Management by Sight


So what this all about? Let me try to explain the need for this:

• Manager, and why not engineers, are busy people who don't have time to crunch numbers to see how they're progressing in the project
• Everybody cares about measuring progress, but managers are just big fans of it
• So, we need something that people can look and instantaneously, and why not magically, can tell them whether they're on track or falling behind schedule

Once we all realize that we need some light here, we're ready to look into what Toyota discovered years ago: a simple chart that shows progress


But some conditions for the magic to work:

1. It has to be visual (obviously!)
2. It has to be public
3. It has to be periodically updated
4. It has to be easy to read
5. It has to be easy to understand
6. It's interpretation has to be clear
7. Only a few indicators should be considered per graph, don't try to show everything in just one chart
8. It has to be a communication vehicle for the team
9. It has to have real data, not massaging information should be allowed
10. It's a tool for the team, not just for managers

The Mythical Scrum Master

Once upon the time there was an all powerful individual full of charm and personality, his energy and intelligence what nothing from this world. His voice was like a thunder and he has this magic thing for solving everybody's problems: his name was The Scrum Master

Unfortunately this is just a myth, no such thing exist or at least can be easily found in just one individual. But let's go one step back, why people created a myth around this character? There are some reason that I can think about:

1. From a management perspective it's easier to concentrate all responsibilities -and powers- in just one individual
2. From a team perspective it's times easier to expect that somebody leads the team and solve problems
3. Concentration of responsibilities in one individual is the worst enemy of team empowerment and the great ally of micromanagement
4. Blaming only one individual in case of failure is less harmful to morale than blaming the whole team

So what can we do to kill the myth? Several things I guess:

1. People believes in myths because they try to avoid reality, so let's start there recognizing that there's no Super Scrum Master
2. Like it happened in old towns, myths will be erased via education -so let's start by educating managers and teams
3. But education people on what? Short answer: Scrum
4. Micromanagement is good as long as the team is in charge of it: micromanagement of the team by the team is what we're looking for

When the Product Owner Has to Say No

Saying no to the team, to the client or the Scrum Master, is one of the PO's more important tasks, but let's think in some situations when this might happen:

1. When the team wants to force the client to use a technology, platform, architecture or design that it believes that is "technically suitable" but has no value for the client -I know what is best for you syndrome-
2. When the client wants something that is clearly unfeasible with the given schedule and resources -the dreamer syndrome-
3. When the Scrum Master representing the team wants to change the scope for the project -two captains one boat syndrome-
4. When the team voted and decided what should be excluded from the product -technical decision without business support syndrome-
5. When developers want to work on an overkill solution for a problem -super engineer syndrome-
6. When the team wants to investigate during several sprints without guarantying practical results -researcher syndrome-
7. When the team and Scrum Master want to skip demos -ostrich syndrome-
8. When the team want to exclude the PO from all meetings because they believe they already understand the product well enough -come back when it'll be ready syndrome-
9. When the client want to communicate directly with the team bypassing the PO -serve yourself syndrome-

Syndromes Origin

Even though these syndromes are very common, their origins are still fuzzy, some might be:

1. The PO is not making a good job gathering requirements
2. The PO is not making a good job communicating requirements to the team
3. The PO is not making a good job tracking Sprint progress and backlog evolution
4. The PO is not making a good job interfacing with the Scrum Master
5. The PO is not making a good job buffering the team from external influences
6. The PO is not making a good job setting priorities
7. The PO is not making a good job using her charisma to lead/influence the team/client in the right direction

Whatever reason that is forcing the PO to says no to the team, these seems to indicate a disruption in the PO role an performance. After all a NO is not required if everybody is clear in what should be done.

Many NOs accumulated in the course of a project are a symptom of a failure in the PO performance. But in any case is times better that the PO says no and correct her course than letting things flow in a direction that will take the project to a failure.

Another of my Articles Published by the Agile Alliance

Another article written by me, Definition of Done and the Quest for the Potentially Shippable Product, has been recently published by the Agile Alliance: see this link http://www.agilealliance.org/articles_by_category?id=17

The Illusion of Control

Buddhists believe that the control is just an illusion, people fond to control things suffer to much when they realize that they can't control everything.

Buddhists recipe for happiness (and please don't take this literally) is not creating tight bonds to anything or to anybody, just let things flow and interact without forcing control.

What I found interesting in this philosophy is that managers tend to devote much of their time and effort to craft complex control devices, dashboards, and metrics loosing perspective that in Scrum everything is about micromanagement, but not micromanagement of the team by the manager. Micromanagement of the team by the team itself is times more efficient.

If a team learns how to manage itself, the illusion of control won't be necessary any more, managers will become coaches, and will sleep better at night.

Is the Product Owner a Villain?

Short answer, yes. Long answer, still yes.

The PO hasn't has to be a villain, only look sometimes like one in front of her team.

Why such a nice gal like the PO has to look though? Simple, if she doesn't, team members will end up imposing whatever they believe that the user should need from a system rather than to hearing to user's requirements.

By the same token, as a user's representative, the PO is in charge of sometimes say "your work is not what what I need, I can't sell that to clients, you need to redo it". The team will be close to kill the PO but in the long run her firm hand rejecting not good user stories or asking for work to be redone will be key for taking the ship to good harbor.

Dirty work PO's it is, but somebody has to do it. May the force guide your steps POs.

Scrum Bolivia User Group in the Agile Alliance

Our Scrum Bolivia User Group is now officially registered in the Agile Alliance group listing, see http://www.agilealliance.org/show/1641

When Pigs Become Chickens

I received and interesting question, somebody asked me about some reasons why a pig might become a chicken I can think in a few:

1. The pig is a low performer and she is as productive as a chicken
2. The pig's motivation is so low that she acts like a chicken
3. The staff was reduced and we have less pigs or some were reassigned to other projects but still play chicken's role in our
4. Part time engineers that switch among projects and don't really contribute to any
5. Upper managers who like to play pig's role but run away when they have to get their hands dirty with complicated tasks

Mechanics and the Myth of the Satisfied Client

It’s always a true in software development that we try to satisfy clients believing that they’re always right and they always know what they want. Further, we tend to think on them like almighty goddess with unlimited decision powers. But let’s think it twice, why should we be more committed to customer satisfaction than other service industries?

Let’s take this example from real life, my real life at least. I took my car to the car shop because the front wheels were making some funny noise whenever I slammed on the brakes. The mechanic when below the car, took a look and found nothing. I insisted in that the car was making noises when I drove it, the mechanic said let’s take it for a test ride. I drove the car, slammed on the breaks and again nothing: no noises, no breaks failure no nothing. The mechanics just smiled to me and charge me a no cheap fee for his time.

As a customer, what was my problem? Did my car really have a problem? It was a random not easily reproducible bug? Honestly, I don’t know, but I’m sure that I’m not crazy and the noise was there. So the point is, does the client have enough knowledge to diagnose problems? More to the point, what approach the mechanic used to try to pin down the problem with my car? No big up front requirements, the mechanic uses and iterative approach for diagnosing, fixing is incremental and many times mechanics have to inspect and adapt their work as they move.

Lastly, mechanics usually don’t tell us how much they’ll charge us for their services; they complete the work and then ask for payment. Most of the time your car is fixed and you paid without questions. What a wonderful life mechanics have, don’t you think? Something that we can copy?

My article has been Published by the Agile Alliance

An article that I wrote last month, Key Metrics for Measuring Sprint Status, has been published by the Agile Alliance, see this link http://www.agilealliance.org/articles_by_category?id=10

The full article can be also found in this blog: http://juanbandaonscrum.blogspot.com/2009/08/key-metrics-for-measuring-sprint-status.html

Scrum Bolivia User Group on Twitter

The Scrum Alliance officially announced the creation of the Scrum Bolivia User Group on Twitter.

The Scum Bolivia Yahoo! User Group has been Created

Finally the Scrum Bolivia has an official User Group where Scrum Practitioners can meet to share experiences and learn from each other, this is an open group so no moderator approval is required. The link to this group is http://tech.groups.yahoo.com/group/scrumbolivia/



The Scrum Alliance also made public the creation of this group, and include it in its listing of official groups, see this link http://www.scrumalliance.org/user_groups/74

Plan for the Sprint vs. Sprint Planning

A typical question that comes from teams is how much planning should be made for before starting a Sprint? Further, what should we plan for? These are fair questions without direct answers. Let’s start trying to solve this puzzle one piece at the time.

What is planning?

According to Wikipedia, planning is “…the psychological process of thinking about the activities required to create a desired goal on some scale”. So, if planning involves thinking next questions should be, is this an individual or collaborative activity? The answer for this seems to be quiet intuitive, it’s an individual activity that is performed in a group but not necessarily a team activity.

What is Sprint Planning?

Is the stage in which the team, and when I say the team I mean everybody that actively will contribute during the Sprint (no chickens sorry), gets together in a single room for an X number of hours and try to define what to do. Focus on what and not how. One tip: don’t let the Product Owner run without answering all your questions, lock the door if necessary.

Plan for the Sprint

This is not the Sprint planning stage; this has to do with more tangible things like: capacity planning, logistics and infrastructure. For instance, consider you will be taking vacation and what type of environments or licenses are you going to need in the Sprint. Some other questions might to consider:

• Should I have to use Agile/Scrum for plan for the Sprint? Not necessarily, since this is a support part necessary for the sprint but not under the scope of the team.
• Who should take care of this? Somebody in your Management and/or IT staff.
• Is this really important for the Sprint? Absolutely, you can’t have a Sprint without knowing what resources you’d be committing.

Question on Why we're Always Late

• Why we always have Quality Engineers and Info Devs trying to catch up with development? Is this because development is moving too fast and QE/ID too slow? Or is this because development moves to slow holding back QE and ID work? We shouldn’t be asking this questions in the first place if we consider everybody as part of a single team (no dev, QE, and ID for separate) and we have a consolidated Definition of Done. DoD is what can tell us if a user story is really completed or half baked. DoD should be common and all team should aim to complete user stories under this definition.
• One step back, why we plan for more than we can achieve? Part of this is because we don’t plan thinking as a team, development plan first and then QE and ID add their estimates. Development estimates might fit whiting the timeboxed iteration but QE and ID would most likely fell of the mark. The other part of this is because we don’t know for certain team velocity.
• Why we don’t know team velocity? We measure progress in hours but we plan in user stories, our backlog contains user stories that when moved to iterations are tracked down using burn hours. What Scrum recommends is using burn down charts for user stories not for hours. Burning hours is not a good indicator of progress, on the contrary, it often mislead us when we try to evaluate iteration progress.
• Velocity could be better indicator if we can estimate the number of user stories that the team is able to produce in an iteration. However, story points or other metric should be considered to have a correlation metric for user stories’ size and complexity.
• Are carried over user stories that bad? Without question carrying over user stories break the Scrum principle of having a Potentially Shippable Product at the end of each Sprint. Moreover, from a production stand point, carried over user stories creates a technical debt that will drain team’s capacity in the future.