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.