How Do We Fill Up a Sprint?
Questions that prompted this note :
“We were in Sprint Planning and had selected several Product Backlog items. We found that we were not able to fit another Product Backlog item, but still had some time left available in the Sprint. What should we do with that available time?”
Some might suggest we could take the next priority Product Backlog item and break that into smaller items so we could select an appropriately estimated item and fill out the Sprint. While this solution works, I’m not too keen on having to break down items further just to fill in potentially small pieces of time. My preference is to take a portion of the next priority item and begin working on that during the additional time available. How would this work?
As the team completes their selection and decomposition (Sprint Planning, parts I and II), I expect that they make a goal statement, or a statement of commitment, expressing what it is exactly that they are committing to. In this situation their goal statement might sound something like this: “We’ll deliver the following priority items from the Product Backlog: the XML interface to Atlas Data Services will be built, the front-end tool for placing orders will have the demographic data stored in the new database, and the accounting reconciliation report will be completed. Additionally, we will begin work on our new API function that delivers order information to interested customers.”
As you can see, we still commit to those first three items that fit within the Sprint, and we let the Product Owner know that we will also begin on a fourth item, but there’s no commitment that we will be able to complete that item, just that we will start on it. This would require of course that we would need to decompose that fourth item into manageable tasks so we could indeed begin working on it.
The decomposition of the next priority item is something I ask teams to do as normal practice even when they have a good fit of Product Backlog items and have no additional time left over. Why? I think it’s helpful for teams to look a bit beyond just the exact content of the current Sprint and see what’s coming next. It helps crystallize the vision of where the product is headed, and gives the team some insight into design considerations for items that are coming next. Additionally, they will always have a decomposed Product Backlog item ready to be worked in case they finish early. True, the time spent decomposing could be wasted if the Product Owner decides to change priority at the next Sprint Planning Meeting, but we’re not spending an inordinate amount of time on this, putting most of our time and focus on the highest priority items.
Please note that this approach assumes that we are decomposing all of our work into manageable tasks at the Sprint Planning Meetings and not during the Sprint. Only teams that are well integrated and experienced should consider leaving items for decomposition as the Sprint is progressing. There’s simply too much risk in expecting a loose or inexperienced team to deliver on their commitments without going through decomposition first.
You may wish to use my principle here when working with your team: “No waste, please,” meaning that we do not plan loosely and allow for gaps of unallocated time in our plan simply because Product Backlog items don’t fit neatly into the time we have.
From classroom training (ranging from 2-hour overview sessions to 2-day Certification Training) to organizational consulting, we can help with all your IT project needs. If you would like to learn more, call us at 954-575-8766, or email us at info@winnowmanagement.com
You linked to Scrum Notes from the Home page.