Tag Archives: Planning

If Your Up-Front Planning is Measured in Weeks, Then a Lean Startup is Going to Eat Your Lunch

Learn more about transforming people, process and culture with the Real Agility Program

Title inspired by Michael James…see below.

One of the most powerful assumptions built in to Agile methods is that we learn by doing — that our learning, our planning, our problem-solving, and ability to mitigate risk is enhanced when planning is performed inline with active development and in the context of deliberate experimentation.  Scrum, for example, is based on empirical process control theory which means that we make decisions based on what is known.

One of the most common pitfalls we see among organizations trying to “adopt” Agile is excessive pre-planning — their assumption being that we can decide by planning, learn by planning, or mitigate risk by planning.  This sometimes manifests as an anti-pattern that people call “Sprint Zero” — a signal that an organization misunderstands Agile methods fundamentally.  More importantly, a signal that the organization may incorrectly perceive Software Engineering — or any team-based work — as predictable and repetitive rather than the complex, creative endeavor that it is.

If your organization injects a “Sprint Zero” or a planning phase (that is measured in weeks rather than days or hours) ahead of the creation/development of real product, then these two posts are of interest to you:

Please share!

9 Agile Estimation Techniques

Learn more about transforming people, process and culture with the Real Agility Program

Many people have used a variation of Planning Poker to do Agile estimation.  Here is a reference of 9 different Agile estimation techniques for different circumstances.  I have seen all of these techniques work in practice, except one.  Try a new one each Sprint!

Planning Poker

Participants use specially-numbered playing cards to vote for an estimate of an item.  Voting repeats with discussion until all votes are unanimous.  There are lots of minor variations on Planning Poker.  Good technique to estimate a very small number of items (2 to 10).

The Bucket System

Using the same sequence as Planning Poker, a group or a team estimate items by placing them in “buckets”.  The Bucket System is a much faster Agile estimation technique than Planning Poker because there is a “divide-and-conquer” phase.  The Bucket System can also be used with larger groups than Planning Poker and with very large numbers of items to be estimated (50 to 500).


For super-fast Agile estimation, the items to be estimated are simply placed by the group in one of three categories: big, uncertain and small.  The group starts by discussing a few together, and then, like the Bucket System, uses divide-and-conquer to go through the rest of the items.

TFB / NFC / 1 (Sprint)

This Agile estimation technique is similar to Big/Uncertain/Small but puts a specific “size” into the mix, namely 1 Sprint.  The categories are “Too F-ing Big”, “No F-ing Clue” and “1” Sprint (or less).  I learned this one recently from someone in one of my CSPO classes.

Dot Voting

Dot voting is usually considered a decision-making tool, not an Agile estimation technique.  However, for estimating small numbers of items, dot voting can be a super-simple and effective technique.  Each person gets a small number of “dots” and uses them as votes to indicate the size of an item; more dots means bigger.

T-Shirt Sizes

Items are categorized into t-shirt sizes: XS, S, M, L, XL.  The sizes can, if needed, be given numerical values after the estimation is done.  This is a very informal technique, and can be used quickly with a large number of items.  Usually, the decisions about the size are based on open, collaborative discussion, possibly with the occasional vote to break a stalemate.  There is a brief description of T-Shirt Sizes here.

Affinity Mapping

Items are grouped by similarity – where similarity is some dimension that needs to be estimated.  This is usually a very physical activity and requires a relatively small number of items (20 to 50 is a pretty good range).  The groupings are then associated with numerical estimates if desired.

Ordering Protocol

Items are placed in a random order on a scale labeled simply “low” to “high”.  Each person participating takes turns making a “move”.  A move involves one of the following actions: change the position of an item by one spot lower or one spot higher, talking about an item, or passing.  If everyone passes, the ordering is done.  The Challenge, Estimate, Override and the Relative Mass Valuation methods are variations on the ordering protocol.

Divide until Maximum Size or Less

The group decides on a maximum size for items (e.g. 1 person-day of effort).  Each item is discussed to determine if it is already that size or less.  If the item is larger than the maximum size, then the group breaks the item into sub-items and repeats the process with the sub-items.  This continues until all items are in the allowed size range.

Principles of Agile Estimation

Agile estimation techniques are collaborative.  All appropriate people are included in the process.  For example the whole Scrum team participates in estimating effort of Product Backlog Items.  Collaborative techniques are also designed so that it is impossible to blame someone for an incorrect estimate: there is no way to trace who estimated what.

Agile estimation techniques are designed to be fast (-er than traditional techniques) and deliberately trade off accuracy.  We are not trying to learn to predict the future… or get better at estimation. Instead, we recognize that estimation is a non-value added activity and minimize it as much as possible.

Most Agile estimation techniques use relative units.  This means that we don’t try to estimate dollars or days directly.  Instead, we use “points” or even qualitative labels and simply compare the items we are estimating to each other.  This takes advantage of the human capacity to compare things to each other and avoids our difficulty in comparing something to an abstract concept (such as dollars or days).

Check out my recent “Agile Planning in a Nutshell” article.

What Other Agile Estimation Methods Are There?  Please let me know in the comments and feel free to include a link!

Please share!

Collaborative Estimation Technique: Challenge, Estimate or Override (CEO)

Learn more about transforming people, process and culture with the Real Agility Program

Great technique described by Shahin Sheidaei on his blog: Challenge, Estimate or Override (CEO) Game for Effective Estimations.  It is much quicker than the Planning Game, and probably a bit slower than the Bucket System.

Please share!

Agile Planning in a Nutshell

Learn more about transforming people, process and culture with the Real Agility Program

Agile methods such as Scrum, Kanban and OpenAgile do not require long-term up-front plans.  However, many teams desire a long-term plan.  This can be thought of as a roadmap or schedule or a release plan.  Agile planning helps us build and maintain long-term plans.

Agile Planning Process

The steps to do this are actually very simple:

  1. Write down all the work to be done.  In Scrum these are called “Product Backlog Items”, in Kanban “Tasks” and in OpenAgile “Value Drivers”.
  2. Do some estimation of the work items.  Many Agile estimation techniques exist including Planning Poker, The Bucket System, Dot Voting, T-Shirt Sizes.  These tools can be applied to many types of estimation.  There are three kinds of estimation that are important for Agile Planning:
    1. Estimating relative business value.  Usually done with the business people including customers and users.
    2. Estimating relative effort.  Usually done by the Agile team that will deliver the work.
    3. Estimating team capacity.  Also done by the Agile team (this is sometimes called “velocity”).
  3. Create the long-term plan.  Use the team capacity estimate and the sum of all the effort estimates to come up with an estimate of the overall time required to do the work.  (In Kanban, which doesn’t have an iterative approach, this is a bit more complicated.)  Use the business value and effort estimates to determine relative return on investment as a way to put work items in a logical sequence.

Agile planning allows a team to update estimates at any time.  Therefore, the techniques used above should not be thought of as a strict sequence.  Instead, as the team and the business people learn, the estimates and long-term plan can be easily updated.  Scrum refers to this ongoing process at “Product Backlog Refinement”.

Principles of Agile Planning

In order to use Agile planning effectively, people must be aware of and support the principles of Agile planning:

  1. Speed over accuracy.  We don’t want to waste time on planning!  Planning in and of itself does not deliver value.  Instead, get planning done fast and use the actual delivery of your Agile team to adjust plans as you go.
  2. Collaborative techniques.  We don’t want to be able to blame individuals if something goes wrong.  Instead, we create safe estimation and planning techniques.  Inevitably, when an estimate turns out to be wrong, it is impossible to blame a single individual for a “mistake”.
  3. Relative units.  We don’t try to estimate and plan based on “real” units such as dollars or hours.  Instead, we use ordering, relative estimation and other relative techniques to compare between options.  Humans are bad at estimating in absolute units.  We are much better at relative estimation and planning.

Please share!

Pitfall of Scrum: Excessive Preparation/Planning

Learn more about transforming people, process and culture with the Real Agility Program

Regular big up-front planning is not necessary with Scrum. Instead, a team can just get started and use constant feedback in the Sprint Review to adjust it’s plans. Even the Product Backlog can be created after the first Sprint has started. All that is really necessary to get started is a Scrum Team, a product vision, and a decision on Sprint length. In this extreme case, the Scrum Team itself would decide what to build in its first Sprint and use the time of the Sprint to also prepare some initial Product Backlog Items. Then, the first Sprint Review would allow stakeholders to provide feedback and further develop the Product Backlog. The empirical nature of Scrum could even allow the Product Owner to emerge from the business stakeholders, rather than being assigned to the team right from the start.

Starting a Sprint without a Product Backlog is not easy, but it can be done. The team has to know at least a little about the business, and there should be some (possibly informal) project or product charter that they are aware of. The team uses this super basic information and decides on their own what to build in their first Sprint. Again, the focus should be on getting something that can be demoed (and potentially shippable). The team is likely to build some good stuff and some things that are completely wrong… but the point is to get the Inspect and Adapt cycle started as quickly as possible. Which means of course that they need to have stakeholders (customers, users) actually attend the demo at the end of the Sprint. The Product Owner may or may not even be involved in this first Sprint.

One important reason this is sometimes a good approach is the culture of “analysis paralysis” that exists in some organizations. In this situation, an organization is unable to do anything because they are so concerned about getting things right. Scrum is a framework for inspect and adapt and that can (and does) include the Product Backlog. Is it better for a team to sit idle while someone tries to do sufficient preparation? Or is it better to get started and inspect and adapt? This is actually a philosophical question (as well as a practical question). The mindset and philosophy of the Agile Manifesto and Scrum is that trying to produce valuable software is more important that documentation… that individuals and how they work together is more important than rigidly following a process or tool. I will agree that in many cases it is acceptable to do some up-front work, but it should be minimized, particularly when it is preventing people from starting to deliver value. The case of a team getting started without a product backlog is rare… but it can be a great way for a team to help an organization overcome analysis paralysis.

The Agile Manifesto is very clear: “The BEST architectures, requirements and designs emerge out of self-organizing teams.” [Emphasis added.]

Hugely memorable for me is the story that Ken Schwaber told in the CSM course that I took from him in 2003.  This is a paraphrase of that story:

I [Ken Schwaber] was talking to the CIO of a large IT organization.  The CIO told me that his projects last twelve to eighteen months and at the end, he doesn’t get what he needs.  I told him, “Scrum can give you what you don’t need in a month.”

I experienced this myself in a profound way just a couple years into my career as an Agile coach and trainer.  I was working with a department of a large technology organization.  They had over one hundred people who had been working on Agile pilot projects.  The department was responsible for a major product and executive management had approved a complete re-write.  The product managers and Product Owners had done a lot of work to prepare a product backlog (about 400 items!) that represented all the existing functionality of the product that needed to be re-written.  But, the big question, “what new technology platform do we use for the re-write?” had not yet been resolved.  The small team of architects were tasked with making this decision.  But they got stuck.  They got stuck for three months.  Finally, the director of the department, who had learned to trust my advice in other circumstances, asked me, “does Scrum have any techniques for making these kind of architectural decisions?”

I said, “yes, but you probably won’t like what Scrum recommends!”

She said, “actually, we’re pretty desperate.  I’ve got over a hundred people effectively sitting idle for the last three months.  What does Scrum recommend?”

“Just start.  Let the teams figure out the platform as they try to implement functionality.”

She thought for a few seconds.  Finally she said, “okay.  Come by this Monday and help me launch our first Sprint.”

The amazing thing was that the teams didn’t lynch me when on Monday she announced that “our Agile consultant says we don’t need to know our platform in order to get started.”

The first Sprint (two weeks long) was pretty chaotic.  But, with some coaching and active support of management, they actually delivered a working increment of their product.  And decided on the platform to use for the rest of the two-year project.

You must trust your team.

If your organization is spending more than a few days preparing for the start of a project, it is probably suffering from this pitfall.  This is the source of great waste and lost opportunity.  Use Scrum to rapidly converge on the correct solutions to your business problems instead of wasting person-years of time on analysis and planning.  We can help with training and coaching to give you the tools to start fast using Scrum and to fix your Scrum implementation.

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.

[UPDATE: 2015/08/19] I’ve just added a video to the “Myths of Scrum” YouTube series that adds a bit to this:

Please share!

Design Debt & UX Debt is Technical Debt

Learn more about transforming people, process and culture with the Real Agility Program

Hey! Let’s all work together, please.

Technical Debt is a term which captures sloppy code, unmaintainable architecture, clumsy user experience, cluttered visual layout, bloated feature-sets, etc.  My stance is that the term, Technical Debt, includes all the problems which occur when people defer professional discipline — regarding any/every technical practice such as product management, visual and UX design, or code.

I assert that the change we need to catalyze in the business community is larger than any one discipline and I am worried that I have seen an increase in blog articles in recent years about concepts like “Design Debt”, “UX Debt”, “Experience Debt” — these articles unfortunately are not helping and have served only to divide the community. They are divisive, not because we shouldn’t be discussing the discreet facets in which Technical Debt can manifest, but because authors often take a decidedly combative approach in their writing.  Take these phrases for example:

  • “Product Design Debt Versus Technical Debt” written by Andrew Chen
  • “User Experience Debt: Technical debt is only half the battle” written by Clinton Christian
  • “Design debt is more dangerous because…” written by James Engwall.

I agree with Andrew Chen that Product Design Debt is a problem — I just don’t like that he chose to impose a dichotomy where there is none.  Why must he argue one “versus” another?  Clinton Christian has implied that we’re in a “battle”.  James Engwall has compared the “danger” of Design Debt relative to Technical Debt.  These words are damaging, I argue, because they divert attention to symptoms and away from root causes.

The root cause of Technical Debt is that people forget this simple principle of the Agile Manifesto: “Continuous attention to technical excellence and good design enhances agility.”

The root solution to Technical Debt — all of its forms — is to help business leaders realize there is a difference between “incremental” development and “iterative” development so they may understand the ROI of refactoring.  No technical expert should ever have to justify the business case for feature-pruning, refreshing a user interface, refactoring code, prioritizing defects.  Every business leader should trust that their technical staff are disciplined and excellent.

Yes, please blog about UX Debt and Product Development Debt, etc.  But please do so in a way that encourages cohesion and unity within the Product Development community.

Please share!

When the team says, “we need detailed requirements before we can estimate”…

Learn more about transforming people, process and culture with the Real Agility Program

The next time the team says “we can’t estimate without better requirements” what they actually mean is, “this is crazy, but hey…if you think you can accurately predict all the exact requirements and you can guarantee that nobody in this company will change their minds about those requirements between this moment and forever, then we’ll give you an estimate to hang your hat/noose on.”

Every group responsible for the creation and delivery of software (or any complex/creative product for that matter) will experience dissonance between the need to plan and the need to obey the laws of nature which prevent us from travelling through time and future-telling.  Business leaders have to finance the development of product; creative and technical leaders have to solve complex problems amidst dynamic, unpredictable, circumstances.  These conditions manifest as a dichotomy which is difficult to mediate (at best) and/or downright toxic (at worst).

On one hand, a common sentiment among project managers is: “The problem I have with the release planning stage is that without clear requirements, the developers don’t like to give estimates, even with story points.”

On the other hand, a common sentiment among developers is: “Stakeholders don’t understand what they’re asking for, if they knew the complexity of our technology they wouldn’t be asking those questions.”

If developers don’t like to provide estimates, it is likely because others in the organization have used their estimates as though they are accurate predictions of future. Thus, when said estimates turn out to be inaccurate they are used as punitive metrics in conversations about “commitment” and “velocity” and “accountability”.


Please share!

5 Things Agile Leaders Must Do

Learn more about transforming people, process and culture with the Real Agility Program

From the full article “5 Things Agile Leaders Must Do“:

  1. Uphold self-organization.
  2. Formalize Agile roles.
  3. Understand that Scrum is not the only Agile method.
  4. Stop up-front planning.
  5. Lead by example.

Consider enrolling in our Scrum and Enterprise Agile for Executives ½ day seminar in Toronto.

Please share!

Best Agile Advice Articles – Ten Year Anniversary!

Learn more about transforming people, process and culture with the Real Agility Program

Agile Advice was started in 2005.  In ten years, we have published over 850 articles (an average of just about 2 per week!).  Here are some collections of the ten “best” articles.  I hope you enjoy looking back at (or discovering for the first time!) some of the things that have made this such a great joy for me.

Ten Most Popular Agile Advice Articles

  1. How Two Hours Can Waste Two Weeks (75,000+ visits)
  2. The Seven Core Practices of Agile Work (25,000+ visits)
  3. Eight Barriers to Effective Listening (17,000+ visits)
  4. Seven Essential Teamwork Skills (17,000+ visits)
  5. 24 Common Scrum Pitfalls Summarized (15,000+ visits)
  6. Mentoring and Coaching: What is the Difference? (14,000+ visits)
  7. Wideband Delphi Estimation Technique (14,000+ visits)
  8. The Pros and Cons of Short Iterations (13,000+ visits)
  9. Three Concepts of Value Stream Mapping (13,000+ visits)
  10. Agile Work and the PMBoK Definition of Project (11,000+ visits)

Ten Most Commented Upon Agile Advice Articles

  1. 24 Common Scrum Pitfalls Summarized (19 comments)
  2. Agile Becomes Easier with Useful Tools (12 comments)
  3. Important Words about Scrum and Tools (9 comments)
  4. The Skills Matrix and Performance Evaluation on Agile Teams (9 comments)
  5. The Definition of Done is Badly Named (8 comments)
  6. How Two Hours Can Waste Two Weeks (7 comments)
  7. Agile is Not Communism (7 comments)
  8. Agile Tools vs. Agile Books (6 comments)
  9. The Decline and Fall of Agile and How Scrum Makes it Hurt More (5 comments)
  10. The Planning Game: an Estimation Method for Agile Teams (5 comments)

I also want to acknowledge that there are a number of other contributors to Agile Advice besides me (Mishkin).  These contributors are all experts, all have great experiences, and all are fantastic people to know.  I’m grateful for their contributions since they have all made Agile Advice a better place to browse!

Five Most Frequent Contributors (of Articles, besides Mishkin)

  1. Paul Heidema (34 articles)
  2. Travis Birch (24 articles)
  3. Christian Gruber (19 articles)
  4. Mike Caspar (16 articles)
  5. Shabnam Tashakour (13 articles)

Plans for the Future – Five Top Ideas for Series

  1. Essays on each of the Values and Principles of the Agile Manifesto
  2. Summary articles of several Agile methods including Scrum, OpenAgile, Kanban, Crystal, XP, and others
  3. Real Agility Program case studies
  4. Reviews of other scaling / enterprise Agile frameworks such as Disciplined Agile Delivery, Large Scale Scrum, Enterprise Scrum
  5. New guest articles from thought and practice leaders.

Please share!

Scrum “Inputs”

Learn more about transforming people, process and culture with the Real Agility Program

The Product Backlog is often described as the primary input to Scrum.  The Sprint starts with Sprint Planning and Sprint Planning starts with the Product Owner and the Product Backlog.  In principle, this makes perfect sense and hopefully it is enough for most teams and organizations to just start with the Product Backlog.  And if you don’t have a Product Backlog, then just start without one, get some stuff done that the team thinks is important, invite some people to the Sprint Review and most likely one of those people will end up becoming the Product Owner and gradually take on the responsbilities of that role.  I believe in just starting if you can.  I even wrote a blog post about this a while back and I stand by it.

I have served as a Scrum Master and coach for a number of teams and I have identified some patterns that I think are worth addressing.  Newly-formed teams tend to ask for (and need) a little more help than this in order to feel ready to start.  And I have learned from experience that it is usually more effective for the adoption of Scrum and team development for the team to feel ready enough to just start.

The Scrum Guide recognizes the following inputs to Sprint Planning:

  • Product Backlog
  • Latest product increment (not applicable to first Sprint)
  • Projected capacity of the Development Team during the Sprint
  • Past performance of the Development Team (not applicable to first Sprint)
  • Definition of “Done” (implicitly)

A newly-formed team often needs to address the following before the first Sprint:

  • Product Backlog
  • Projected capacity of the Development Team during the Sprint
  • Definition of “Done”

If these are not addressed before the first Sprint, then they will likely need to be addressed during Sprint Planning, which can place a lot pressure on a new team (especially in environments where it is difficult to build shared understanding of the work).

Product Backlog

Keep it simple.  It’s an ordered list of all the features, functions, enhancements and fixes that might be needed in the end product.  Get the Product Owner to blow these things out into a list.  It doesn’t need to be a complete list.  Just the most important things right now.  A good test is to give the Product Owner 5 minutes.  Whatever the Product Owner can think of in 5 minutes is important enough for the team to start working on.  There are all kinds of techniques that can be used to order the Product Backlog.  The simplest way is to just have the Product Owner eyeball it.  If people are uncomfortable with this, then introduce the other ways.  It doesn’t need to be perfect.  It will get better and become refined and adapted as you go.

Projected capacity of the Development Team during the Sprint

Multiply the number of working days in the Sprint (total days minus Sprint Planning, Sprint Review and Sprint Retrospective, rounding down) by the number of Development Team members by the average percentage team member dedication (hopefully 100%).  If you have weird things going on with team member allocation (not 100%) then you may find it helpful to refer to this blog post.  According to what the Scrum Guide says about Development Team size and Sprint duration, this number could theoretically be smaller (Sprint less than one week), but in most cases no less than 12 (3-member Development Team in a one-week Sprint) and no more than 207 (9-member Development Team in a one-month Sprint with 23 days – the maximum number of weekdays in a month).

Definition of “Done”

This is a list of all of the activities that will go into the intended Increment of the first Sprint in order for it to be done.  The team needs to know this before it can estimate the items in the Product Backlog as a team.  Estimation is not a requirement of Scrum, but is often very helpful in refining the Product Backlog, tracking velocity and making projections into the future based on historical actuals.

Planning with the Product Backlog, projected capacity and Definition of “Done”

In the first part of Sprint Planning, the team looks at the items at the top of the Product Backlog in order to determine what can be done in the Sprint and the Sprint Goal, keeping in mind that it will need to complete the items according to its Definition of “Done”.  Once the team has set a Sprint Goal, it can then create a set of tasks that represent how the work will get done.  All of the tasks should fulfill a specific attribute of the Definition of “Done” or be about the technical parts of the system that need to be built.  The team should try to create a set of tasks each of which are a one-person day effort or less.  Count the number of tasks.  If the number of tasks are close to the number of days of the team’s capacity, the team can be confident that it has a decent Sprint Backlog.  If not, then the the Sprint Backlog and likely the Sprint Goal will need to be adapted.

Please share!

Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game: Adaptive Planning for Adjusted Team Capacity in Scrum

Learn more about transforming people, process and culture with the Real Agility Program

Author’s caveat:

Lots of smart people have already come up with lots of ways of doing adaptive planning, and chances are someone has already come up with some variation of this particular approach. I have not yet had the benefit of reading everything that everyone else has already written about Agile and planning, so this has been generated by my own experiential learning on the ground as an Agile coach.  Sometimes, as a ScrumMaster/Agile Coach, you are called upon to be a two-trick pony.  This is my other trick.

 Requirements for team estimation (and planning):

  • Product Owner
  • The whole Development Team (i.e. everyone who will be involved in doing the work)
  • Product Backlog
  • Definition of “Done”

 When team membership changes:

A Scrum Team that is estimating effort against Product Backlog items for project planning and timeline projections and changes team membership for one or more Sprints must also re-estimate the remaining items (or at least the items that will be part of the Sprints in which the different/additional team members are expected to participate) regardless of estimation method (Agile Planning Poker or otherwise). The people involved in doing the work (Development Team members/Sprint) must also be involved in providing team estimates. The Development Team is responsible for all estimates as a whole team and therefore should provide estimates as a whole team. The Planning Poker game is widely understood by Agile experts and successful Agile teams as the best tool for facilitating team estimation. Part of what makes Planning Poker so effective is that it does not only provide accurate timelines, but it also facilitates knowledge-sharing among team members as everyone on the team is required to endeavor to understand the degree of complexity of the work of all other team members in order to deliver each item according to the team’s Definition of “Done”.

When team member allocation is adjusted:

Sometimes, the Development team will have people partially dedicated to the team. After one or two Sprints, it becomes apparent that full dedication of all Development Team members is required for optimal team performance. As result, management can be assisted to reconsider allocation of team members towards 100% dedication to the work of a single Scrum Team. Increased (or decreased) dedication of team members can also be expected to have a corresponding impact on velocity (effort points completed per Sprint). However, the Scrum Master needs to help the team (and their managers) to be careful to avoid planning against the unknown. Scrum allows a team to adapt based on actual historical data. Therefore, planning against minimum historical velocity is strongly recommended as a general best practice. At the same time, if a team starts off with, say, 50% allocation of team members and management decides to bump it up to 100%, it is fairly safe to assume that you will actually get somewhat more out of the team. How much more is never possible to know, as human beings are reliably incapable of predicting the future. The moderate way to approach this is to plan the next Sprint based on previous velocity, finish the planned work early in the Sprint, get a bunch of “extra” stuff done, then calculate velocity of the new and improved team and plan against the new and improved velocity. This allows the team to adapt to actuals and not be blind-sided by unforeseen impediments/bottlenecks.

Sometimes, there is a need for management to get a sense of how much more velocity the team will get from increased team member allocation in order to feel that an informed decision has been made. There is a simple (though not risk-free) method for doing this that I have whipped up after being put on the spot on several occasions. I have decided to call this the Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game.


The purpose of this exercise is to provide decision-makers with a sense of how much they are going to get out of adjusted allocation of team members to Scrum Teams. Scrum Teams perform optimally when all team members are 100% dedicated to the team. This game should be used with caution and as a means to help organizations move closer to 100% dedication of all Scrum Team members (at least all Development Team members) and, therefore, eliminate the need for this game. Great care should be taken to not encourage perpetuation of dysfunctional Waterfall habits such as “we will now go twice as fast and get done twice as early with twice the allocation of resources because we have this shiny new crystal ball called Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game that tells us so.” As long as no one believes that this is magic, it is likely safe enough to proceed to Step 1.

Step 1 – What is our current velocity?

After the first Sprint, the team should be able to count up the number of Product Backlog items completed and add up the corresponding number of “Effort Points” established during its initial estimation (Planning Poker) sessions. Let’s say for our example that the number completed for Sprint 1 is 21 Effort Points. Therefore, the current velocity of the team is 21. Let’s say that this is not a comfortable realization for the team because at some point in the past it had been estimated that this project would take the team about 5 Sprints to complete. Now, the team has done 21 points in the first Sprint and the total number of Effort Points on the Product Backlog estimated by the team is just under 210. Uh oh… 10 Sprints! Whoops! Now what do we do?! Are the new estimation values wrong? Should we stick to the 5 weeks and just have everyone work overtime on this project? Should we take this to management? Let’s say that this team decides to take it to management. But what if management needs more information than “team velocity = 21, Product Backlog = 210, therefore it’s going to take us 10 Sprints instead of 5”? Never fear, Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game is here!

Step 2 – What is our current capacity?

As part of Sprint Planning, the team needs to have a sense of its capacity in order to create the Sprint Goal and Sprint Backlog. Therefore, the team should already have a sense of its own capacity. Let’s say for our example that the (fictional) Development Team had the following projected allocation for the first Sprint:

50%        Chris P. Codemuncher

50%        Larry Legassifulunch

25%        Beth Breaksidal

40%        Gertrude Gamesthadox

40%        Dana Deadlinedryver

The team is doing 2-week Sprints. After calculating the time that the team has allocated for Scrum Events, the remaining time for doing the work of the Sprint is about 8.5 days. Therefore, we can calculate the total allocated days per team member as such:

8.5 x 50% = 4.25 days    Chris P. Codemuncher

8.5 x 50% = 4.25 days    Larry Legassifulunch

8.5 x 25% = 2.13 days    Beth Breaksidal

8.5 x 40% = 3.4 days      Gertrude Gamesthadox

8.5 x 40% = 3.4 days      Dana Deadlinedryver

17.43                              Total combined available days per Sprint

Let’s round that down to 17. That’s the number used by the team to understand its capacity for Sprint Planning. This is a powerful number for other reasons than what we are trying to get at here, but they are worth pointing out nonetheless. For generating the Sprint Backlog in Sprint Planning, this is particularly useful if each task in the Sprint Backlog is a maximum of a one-person-day. Therefore, this team should have a minimum of 17 tasks in the Sprint Backlog and these tasks should all be a one-person-day or less amount of effort. If the team has more than 17 tasks which are all about a one-person-day of effort, chances are the team has overcommitted and will fail to deliver the Sprint Goal. This should trigger the adaptation of the Sprint Goal. In any case, it provides the team with simple transparency that can easily be inspected and adapted throughout the Sprint. For example, with one-person day tasks, each team member should be able to move at least one task into the “Done” position every day and point to that movement every day during the Daily Scrum. Also, this team should be burning down at least 5 tasks every day. If either of these fails to occur, this is a clear signal for the team to inspect and adapt.

Now, let’s get back to our Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. As a result of Steps 1 & 2 we now know that the team’s velocity is 21 Effort Points and that the team’s capacity is 17 person-days per Sprint. For short, we can say:

21            Velocity

17            Capacity

21/17       V/C

(WARNING: This number is dangerous when in the wrong hands and used as a management metric for team performance)

 Step 3 – How much capacity do we hope to have in the next Sprint?

Let’s say a friendly manager comes along and says “you know what, I want to help you guys get closer to your original wishful thinking of 5 Sprints. Therefore, I’m deciding to allocate more of certain team members’ time to this project. Unfortunately, I can only help you with the ‘developers’, because everyone else reports to other managers. I’m concerned that Beth is going to become a bottleneck, so someone should also speak with her manager. But for now, let’s bump Chris up to 100% and Larry up to 75% and see what that does for you. We’re also going to throw in another ‘specialist developer’ that you need for some stuff in your Product Backlog at 100%. How much more velocity can I get for that?”

Okay. So…more allocation = more capacity = more velocity, right? If we acknowledge that this is highly theoretical, and remember the initial WARNING of the game, we can proceed with caution…

But just as we get started on calculating the adjusted allocation of team members, we find out that Beth was actually more like 50% allocated, Dana was more like 15% allocated and Gertrude was more like 30% allocated. We need to recalculate our actuals for Sprint 1:

8.5 x 50% = 4.25 days    Chris P. Codemuncher

8.5 x 50% = 4.25 days    Larry Legassifulunch

8.5 x 50% = 4.25 days     Beth Breaksidal

8.5 x 30% = 2.55 days     Gertrude Gamesthadox

8.5 x 15% = 1.28 days     Dana Deadlinedryver

16.58                               Total combined ACTUAL available days in Sprint 1

16                                    Actual capacity (rounded-down)

21/16                               Actual V/C

As a side note, Beth had to work on a Saturday in order to increase her capacity but she spoke with her manager and thinks that from now on she will probably be able to maintain this degree of dedication to the team without having to work any more overtime.

Now the team can calculate its hoped-for capacity for Sprint 2 and beyond:

8.5 x 100% = 8.5 days     Sally Supaspeshalis

8.5 x 100% = 8.5 days     Chris P. Codemuncher

8.5 x 75% = 6.38 days     Larry Legassifulunch

8.5 x 50% = 4.25 days     Beth Breaksidal

8.5 x 30% = 2.55 days     Gertrude Gamesthadox

8.5 x 0% = 0 days            Dana Deadlinedryver

(Note: Dana is also the Scrum Master with plenty of other work to do for the team)

30.18                               Total combined hoped-for available days in Sprint 1

30                                     Hoped-for capacity (rounded-down)

Step 4 – How much velocity do we hope to have in the next Sprint?

21            Actual Historical Velocity

16            Actual Historical Capacity

30            Hoped-For Future Capacity

x              Hoped-For Future Velocity

Some simple math, loaded with assumptions:

Actual Historical Velocity/Actual Historical Capacity = Hoped-For Future Velocity/Hoped-For Future Capacity

Therefore if 21/16 = x/30, then x = 21 x 30/16 = 39.375

39            Hoped-For Future Velocity

Step 5 – How do we adapt our planning in light of what we now know (assuming we now know something substantial enough to inform our planning)?

Hopefully, not much. The best thing for the team to do at this point is to plan against its actual historical velocity of 21. If team members finish their work in the Sprint Backlog early, they should help out with other tasks until the Sprint Goal is delivered. Then, if the team achieves the Sprint Goal early and has extra time left before the end of the Sprint, then the team can pull additional items to work on from the Product Backlog. If the velocity of the team actually increases as a result of actual increased capacity, then the team can safely plan against its increased velocity beginning in Sprint 3. However, Hoped-For Future Velocity is often way too tantalizing for a team that already strongly (and to some extent, logically) believes that it can get more done with more capacity. So, most teams will usually plan to do more in light of this knowledge and that’s fine. Scrum allows them to inspect and adapt this plan at least every day. The team will figure it out.

Thank you for playing Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. I hope it was as fun to play as it was to create!

See you next time,


Please share!

Updated: Planning Game for Agile Estimation

Learn more about transforming people, process and culture with the Real Agility Program

I’ve made a minor update to my article about Agile Estimation with the Planning Game to include a downloadable pdf of the article for easy printing.  The downloadable version also includes a tiny bit of commentary that comes from my upcoming Agile Advice book.  There are also two links added at the end of the article.  One is the the wikipedia article about Planning Poker (which describes the method slightly differently), and the other is to an article I wrote a long time ago about the wideband delphi estimation method.

Please share!

The Rules of Scrum: Your Product Owner refines the Product Backlog so it is ready for each Sprint Planning Meeting

Learn more about transforming people, process and culture with the Real Agility Program

The Product Owner is responsible for maintaining the Product Backlog. This includes its ordering in terms of value and effort, its clarity, and identification of what acceptance criteria apply to each Product Backlog Item. It is also very important for the Product Backlog to be ready for each Sprint Planning Meeting so that the team can select the Items for the current Sprint and break those down into tasks. If this is done, the team is able to create an effective Sprint Backlog where it can volunteer for tasks and achieve quick wins each day. If not, the team will likely take on the work of refining the Product Backlog during the Sprint Planning Meeting which is wasteful and not focused. Having a ready Product Backlog helps the team focus during its meetings and ask relevant questions to the Product Owner.

To learn more about Sprint Planning Meetings, visit the Scrum Team Assessment.

Please share!

The Rules of Scrum: I take direction for product vision and scope from my team’s Product Owner

Learn more about transforming people, process and culture with the Real Agility Program

As a Team Member, it is my job to figure out how to solve a problem or request that is stated by a Product Backlog Item (PBI), with the help of my team.  It is the responsibility of the Product Owner to give us the vision of the product and decide how much scope is to be done to satisfy the PBI.  One simple way to think about this concept is that the Product Owner is responsible for the “what” and “why” and the Scrum Team is responsible for the “how” and “who”.  If the Team Members decide on the product vision by themselves, they run the risk of misinterpreting features, moving down a path that is not valuable or even creating work disconnected from the needs of those who will be using the software.  If the Team Members choose their own scope they may do much less than is needed or much more than is required.  There is a balance in the Product Owner providing vision and scope, and the Scrum Team providing knowledge and experience in its execution.

Please share!

The Rules of Scrum: The Sprint Planning Meeting is Timeboxed to 2 Hours / Week of Sprint Length

Learn more about transforming people, process and culture with the Real Agility Program

Timeboxing is the practice of ending a meeting exactly on time regardless of the state of discussion or the desire of participants.  In Scrum, the length of the Sprint Planning Meeting is determined by the length of the Sprint.  For example, a one week long Sprint has a Sprint Planning Meeting that is timeboxed to two hours.  It is acceptable for the meeting to take less time, but not more.  A two week long Sprint has a Sprint Planning Meeting that is timeboxed to four hours.  Keeping the Sprint Planning Meeting timeboxed has two beneficial effects: one, the team keeps the overhead dedicated to meetings to a relatively low level, and two, the team learns to do effective planning in a very short period of time.  If the meeting is not timeboxed, then typically the team will keep planning until the plan is “done” which usually substantially eats into work time.

Please share!