Two Sprint Equations

What should be the order of items to do when installing a Sprint process from scratch? In the coaching days, we requested one to one ratio between the coaches and the rest of the developers plus a project manager, go all out for a couple of sprints, give everyone a chance to adjust to the process, before adjusting the process to the team.

For a single person, the strategy would have to be different. You would need to look at all the practices and make trade-offs with eyes on the big picture. The following two equations are what kept popping into my mind as I am installing the process to the two teams.

Value = Scope * (Feature Quality * Code Quality)

One comment to make here is that during the product development, these three factors are sometimes working against each other. A good business analyst or product manage is one that knows how and when to balance them. Only then, one with a strong personality can bring the best value to the product.

Scope is measurable, as the second section will show. Feature quality and code quality however are simply not something can be determined by objective measurement, not purely on it anyway. When pushed on something like a scope, the things that are not measurable get sacrificed, and everyone ends up paying for it sooner or later.

Scope = Velocity * Number of Sprints

Assuming that the quality of the product is controlled, the scope would be the next thing to look out for during a project. This is pretty easy to understand: the more the team can do without sacrificing the quality (both feature quality and code quality), the better.

Velocity is something that can only be affected by tuning the Sprint process of the team, but can never be demanded. What is left for this equation to work would be to adjust either the scope of the project, or the time of the project (number of sprints), and most of the time both. This is probably one of the commonly stated facts, at the same time it is probably also one of the most ignored fact.

Boosting velocity is the same as boosting productivity of the team, which is the job for the team lead. This is the purpose of a lot of XP practices: TDD, paired programming, co-location, shared ownership, continuous integration.

3 Comments on “Two Sprint Equations”

  1. PM Hut says:

    The velocity concept is way too abstract… Would it be possible to expand more on it?

    Additionally, how do we overcome the obstacle of not being able to measure feature quality and code quality?

  2. Doug says:

    To me, velocity is a stand in for man-hours. The purpose of it is to help prevent management from thinking in terms of the man-hours that a task will take. Instead, we force them, with our involvement, to estimate all tasks in magical ‘points’ instead, and then measure the points completed per sprint as velocity. The benefit is that points are all relative, we expect that task X is 2.5 times as hard as Y, but we don’t know how many hours that will turn into, and that allows us to avoid cutting features short (e.g. not cutting test development for example). So work always gets ‘really done’, and if you want to improve velocity you have to look at what slows down the implementation of tasks and whether or not there is something you can do about it.

    On a philosophical level, the need for ‘points’ really bothers me because it implies that management simply cannot be trusted to participate properly in an agile process.

  3. Shane Duan says:


    My take on the quality is that it is not something that it measurable. Otherwise, it would be called quantity, wouldn’t it? No punt intended.

    The good news is that quality is something that you cannot hide as long as the other side is listening. Have you ever got a team member of high quality and everyone agrees? Do they run some kind of measurement? Probably not. In my opinion, the way you can tell if a product is of good quality is similar to how you can tell if a person is of high quality, by talking to the team member and listen.

    As for the concept of velocity, it is indeed abstract, but for a very good reason, and it can be very concrete if you use it right. It is not a small topic, and I would highly recommend the book “Agile Estimation and Planning” by Mike Cohn for the details.

    I am afraid I cannot agree with the comment on the ‘trust’. I think it is something to be earned and cannot be and should not be demanded. We as software developers indeed don’t have a good track record when it comes to the percentage of failed projects. In my experience, it is not hard to earn trust at all.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s