Waste Not

Category Uncategorized 20 Comments

Waste impedes agility. It not only slows progress, but it robs money that could otherwise go to creating value.

I was considering waste in light of the notions of velocity and capacity. Some Scrum users try to predict the outcome of the upcoming Sprint using velocity, the amount of work or PBIs they predict can be done. One practice used to calculate this velocity is to inspect past velocities and study upcoming team capacity.

I wonder, though. When we start a project or a release, of course we have a general scope, a projected cost, and a probable date. We then move forward, Sprint by Sprint, adjusting our plans to the realities we encounter. We may go faster or slower than expected. We may encounter new opportunities or challenges. We may find that some of what we planned is of lower value than newly emerging requirements.

Let postulate that we ignore velocity and capacity entirely. At the Sprint Planning meeting, the Development Team selects some Product Backlog items and establish a goal. As the Sprint moves forward, they work with the Product Owner to remove PBIs that were more than they could do, or get more PBIs that fit within the goal if they have some time available. At the end of the Sprint, they have done what they have done. At the Sprint Review, the Product Owner, Development Team, and key stakeholders inspect and adapt based on what was completed.

We use short cycle development, with Sprints as short as a week, so that we will frequently know our progress toward our goals, commitments, and projections. I suspect, unless convinced otherwise, that any time we spend worrying about velocity or capacity is waste, not adding a whit of value.

Just thinking,

Ken

20 thoughts on “Waste Not”

  1. What if puzzling about the items to do ‘teachs’ us about them? So the worrying might be waste and the puzzling is learning, then do the puzzle with less worry?

  2. “As the Sprint moves forward, they work with the Product Owner to remove PBIs that were more than they could do, or get more PBIs that fit within the goal if they have some time available.” Does the effort involved in this run the risk of negating the waste you ‘removed’ by not estimating your likely velocity?

  3. Usually PO, SM and team members have issues agreeing on what is a viable goal for the sprint. That is where having an estimated velocity helps. Keeping in mind that PBIs can be added/removed dunring sprint and the end result usually differs from the estimated.
    If you can reach a goal without metrics faster than the few minutes it takes to estimate the velocity, I would agree. It depends a great deal on how mature is your team and the PO.

  4. What you’re saying seems to be slightly in conflict with this from the Scrum Guide: “Various trend burndown, burnup and other projective practices have been used to forecast progress. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making.”

    (especially the last 2 sentences)

    I don’t heavily disagree with what you’re saying, but I think we’d be removing a data point that *could be* valuable from an “inspect and adapt” perspective. OTOH, as we all know, velocity as a metric can be easily defeated.

    I would argue that there is much value in the estimation discussions, so my question is this: If you posit that velocity and capacity discussions are waste, are you also saying that all estimation discussions are waste too?

  5. Thanks for these thoughts.
    Velocity indeed impedes agility if used to make predictions, directly or indirectly invoking stakeholders to use the Sprint Review to check on the delivery of that ‘promise’. That was a compelling reason to replace commitment over selected Product Backlog with a forecast of functionality.
    I fail to see why Velocity would prevent a team to work with the Product Owner during the Sprint to remove or add PBIs as all see fit and agree. At the end of the Sprint they call the amount of Product Backlog they have done ‘Velocity’. Just a finding, that’s not waste. It takes no time and it serves to give some relative likeliness to the future upon open Product Backlog.
    But Velocity is indeed waste if the horizon is of no interest or complexity is so huge that there is no stable horizon.

  6. we are having similar discussions with our teams!

    I think one first step in this discussion is to first define what is meant by ‘velocity’!? Are we refering to ‘velocity’ in the narrow sense of pre-estimated Story Points and hold them against some form of historically burnt Story Points? Or do we refer to ‘velocity’ in a broader sense as to how much do we think can the team accomplish, may this ‘velocity’ be taken out of gut feeling, empirical data (e.g. of doned stories) etc.?

    Once this term is defined, I wonder how you guys would answer the following question (maybe also you question the value of these questions)?

    How would management make investment decisions as to ‘do we want to hire more people into our teams’ to enable them get more done? (I wonder here how they would make a decision on how much the teams get done without a ‘velocity’ in the broader sense)

    How would a Scrum Master measure, how good or how fast his team is and if his team development efforts are fruitful?

  7. I’ve found velocity to be an utterly useless tool, because (at my work) teams are rarely stable over a longer period of time, and we’re often working on projects that only take two or three months. So I never got something valuable out of velocity. Plus, as we all know, people tend to mistake it as a metric which clearly it’s not. Estimation, however, has shown to be useful—not for the actual result, but for the process of coming to a common understanding of what a PBI encompasses. For the actual commitment I really prefer the developers gut feeling over any calculated numbers based on made-up values.

  8. I agree that velocity and capacity are waste for planning a single Sprint. For planning a release they are very valuable.

  9. Once there was a team who used 6 man hour per day capacity to measure total sprint plan. And for months (years??) they used this capacity but having no project improvement.

    Another team once used story points, 20 point velocity but from then on they always measured against this 20 points forecast.

    Is velocity a tool for observing empiricism? Velocity is intended to go from 20 to… 23, 24, 23, 25, 28, 30, 30, 32… Can this be done if “velocity is to inspect past velocities and study upcoming team capacity.”

  10. Pingback: The Daily Scrum, Episode 10 | William Anderson

  11. Pingback: Testando a meta | Blog Lambda3

  12. Hi Ken,

    Interesting thoughts that is leading to some good discussion.

    My reflections —
    I think that if you’re on a team where economics isn’t a consideration, this will work well. E.g. if you’re working with a team funded to serve internal clients for the financial year, the velocity may not matter.

    There could be 1 or more Clients in the organization that need help with 1 or more products driven by software delivery.

    To supplement the above, if the team isn’t working on just 1 product, keeping velocity aside may help, again!

    Now, I wouldn’t get rid of tracking velocity, though, completely. I think this will offer the team an indicator of how they’re doing.

  13. My thoughts…

    The time used to determine team velocity as input for forecasting PBI’s for the next sprint has at least value for me in building tangible confidence with the Development Team. In addition for the Product Owner it provides transparency in regards to progressing towards a goal based on empiricism. Finally the velocity trend also provides transparency in regards to maintaining a sustainable pace or fighting technical debt. Overall valuable input for inspecting and adapting.

    I fully agree that any time worrying about the upcoming team capacity is a waste of time in better predicting the amount of PBI’s that can be done in the next sprint. Given the complex nature of our environment and products we should acknowledge that the impact of team capacity can only be determined in hindsight.

  14. I think, as humans, we love to add complexity on top of easy things. Calculating velocity is one of those things that can be very aleatory, but a lot of people think it is fundamental. I have the suspect that we try to sound intelligent trying to master complicated techniques, rather than keep things simple. Unfortunately complication on top of complexity makes a mess.

  15. Well, I try something foolish, I try to disagree:

    In my current project we didn’t track velocity until last week. We only had 1 Sprint of 12 were we could truly state: “All tasks are DONE”.
    Of course velocity is only useful for stable teams (stable in the sense of what team members work in the team).
    I see velocity tracking as a quality measurement – not code quality, but the quality of the team to predict the efforts needed for some task.
    When you write “As the Sprint moves forward, they work with the Product Owner to remove PBIs that were more than they could do, or get more PBIs that fit within the goal if they have some time available.” than it questions sprints in general. Why should I bother to plan at all, if I can negotiate with the PO what I can deliver?
    A good team has to know what it can do in a sprint. The velocity of the last sprints helps to predict this and the velocity helps to explain to the PO why some tasks can not be in THIS sprint.

    • Try Acceptance Driven Testing and expand the scope of sprint with scenarios. This understanding will engage discussion and enlighten information sharing. Kevin, scrum is used for complex projects. Velocity is not used in a sense of contract to replace inspect, adapt, collaboration and transparency. Mike Cohn uses story points to estimate product backlog and statistical velocity in predicting product delivery. However, he doesn’t use story point for sprint planning.

  16. i appreciate if you share your knowledge an opinion with us. We would to investigate about software dependability in distributed systems which developers are using agile methods, in order to build up a picture of when agile methods should be used, and when they are less effective. Information is being gathered bout projects and teams from a number of different organizations.

    https://docs.google.com/spreadsheet/viewform?formkey=dDEzOC1zN0FJaXd1UkhQVkphU3RrTkE6MQ

  17. So if trading in/out PBL Items mid sprint makes senes and not using to forecast then why use sprints? Seems like a flow based approach like Kanban would serve you better?

  18. Pingback: Killing Agility: One Estimate at a Time – Chris Pipito

Leave a comment