I had an interesting conversation today with one of the software testers in China who was having difficulty understanding some planning concepts in Scrum. She wanted to know if a Scrum team finished all their work early in a Sprint, would it be OK for the Team to take some planned work for the next Sprint into the current. My first response was, “No, that work is already planned for, so the Team takes in a new piece of work that can be completed by the end of the Sprint.” She was having a hard time wrapping her head around the concept until we got to the whiteboard and sketched out what I was thinking. Since it was such a great conversation, I wanted to capture the explanation for others.
Suppose you have a Scrum team and they have constructed the following release plan of their user stories. Each user story has a value (indicated by the $ sign) and a relative size to the others. The total value provided by this Team over the 3 Sprint release is $20.
This is committed work that the Product Owner can take to the stakeholders with reasonable certainty it will be completed when the release date arrives in 6 weeks. When I say reasonable certainty, I mean something along the lines of 85% confidence level. We are very confident all the stuff in the 1st Sprint will be done, less so about some of the low value things in the 3rd Sprint.
Keep in mind when you create an Agile release plan, you are working with incomplete information. We spend just enough time with the user stories to understand the high level scope, high level implementation details and we provide a high level estimate. Since we do not spend a lot of time with the details, our initial estimates for the release plan may be too high or too low. We accept this inaccuracy because it allows us opportunities to provide greater value to the stakeholders and customers.
In practice, this does not present too many problems because there are three forces at work on Scrum teams to ensure the stakeholders get the value they expect (and often times more).
- On Agile teams, the stakeholders are entitled to the most value from each programming week. If the Team has extra capacity, they take on extra work.
- At the beginning of each Sprint, we ask the Team to re-estimate the user stories based on their knowledge of the app, individual skill sets, ability to work as a team and recent experience working with the app. Normally, an implementation detail passed over at release planning with surface during Sprint Planning and that will either make the story real easy or expand the scope. Either way, we have the Product Owner on hand to make adjustments.
- We focus on delivering complete chunks of value, as opposed to coding the most features possible. In Scrum one does not allow unfinished work to cross from one Sprint to the next nor do we allow Scrum teams to start work that cannot be completed by the end of the Sprint. No unfinished work may cross the Sprint boundary.
Back to the original question – if a Scrum team is done early, can they pull stories planned for later Sprints? If the story can be completed within the confines of the timebox, then absolutely yes! Go for it! However, the good Product Owners I have had the opportunity to work with are always looking to add more value to the release, not get things done early. In many large organizations, you don’t get gold stars for getting done early, but you do get praise for getting more done than what was expected, i.e. improving productivity.
What if you were a Product Owner and you could deliver this release plan? In this release plan, the Product Owner has provided $24 of value, as opposed to the original $20 the stakeholders were expecting.
How did the Product Owner do this? Some user stories (blue boxes) were originally estimated to be large, but when implemented, were completed faster than anticipated. There could be a variety of reasons why that is the case (which could be examined in a Retrospective), but the end result is the Team had extra capacity and Product Owner filled the gap with a new user story (green boxes) that could fit within the Sprint. In my experience, these new user stories tend to be extremely valuable to the stakeholders and customers. These are the user stories that just did not make it into the release and their inclusion now are special bonuses. You make people happy with these stories.
But why not pull stories earlier? Can’t you just add all these bonus stories in the last Sprint? You could and it is does not provide any extra value to pull work scheduled for Sprint 3 into Sprint 2. Right now we have a gap in Sprint 2 looking for value. If we pull an item from Sprint 3 we do not add to the total value provided by this Team for the release, we just conserve the amount of value the Team provides.