You can’t fit 10 gallons of water in a 5 gallon bucket

You can’t fit 10 gallons of water in a 5-gallon bucket!

In traditional project delivery, your project team comes together for the duration of that project. Often times at various phases or en masse when trying to crash a schedule.  We put out requests into the organization to staff project team members which creates the size of the bucket (representing capacity in this metaphor). That bucket can be a variable size and work (water)  and capacity (the bucket)  flex depending on the need of scope, timeline and budget. It comes at a cost with high management of capacity and people with skillsets spread across multiple projects.

In agile we build a scrum team with all the skillsets needed for that Product.  It’s a long-lived, dedicated team of 7-11 people that deliver in small increments every sprint. The idea is that the teams stay together to work through Tuckman’s model to achieve the level of performance in order to get the best quality and delivery possible. We flow prioritized work (water) based on their capacity of being dedicated and knowing the product.

Being dedicated to one thing enables teams to reduce lead time, reduce waste in handoffs and turnover, enable them to stop starting and start finishing, and deliver with less cognitive load and higher quality. Imagine working on one thing for 2 weeks at a time! Being persistent enables them to build a level of trust and camaraderie that reduces frictions, welcomes experimentation, and builds unbreakable trust.

In this instance;  capacity (the bucket) is fixed. We don’t crash the schedule, we don’t add and remove team members, it stays constant.

That means that the amount of work also has to stay constant. If a team can deliver 25 user story points (or velocity) per sprint, then they can only pull in 25 story points per sprint. As a side note, velocity is only a means of forecasting. If we had a backlog of 100 story points in this team it would take them 4 + sprints to deliver. It makes planning and forecasting a whole lot easier with a bit of planning!

Those 25 points are as constant as the team is together. Ideally for the product lifecycle continue to build, enhance and maintain the product through new features, production support and the remediation of technical debt. You don’t have to worry about when you will see tech teams again, you just have to worry about what is the priority for them to deliver!

IF the team has completed all those 25, then they absolutely can pull in additional work that they can COMPLETE in a sprint.

We cannot ask them to complete 50 story points in a sprint. That is the equivalent of asking someone to work 80 hours a week. You may think, that they will complete more than the 25!!! I hate to break it to you, your 25 is at risk. The amount of context switching, multi-tasking and WIP will put your 25 at risk. Imagine trying to carry a bucket that’s overflowing. There will be spillage.

Empowering teams that do the work; to plan the work demonstrates trust and creates an autonomy that will pay back in delivery and quality.

Give them the what, a vision, and some context and let them roll!