Work on PBI that is planned to be deployed in next sprint?
If all the planned work, including deployment to production is completed a few days before the sprint ends.
Is it ok if the team decides pull more PBI into the current sprint if they think the work can be done within the current sprint, even if the plan is to not deploy the PBI until in next sprint?
In this situation the reason the team and the PO do not want to deploy the last PBI at the end of the current sprint is because the PBI are not urgent and it will be less risky to deploy them at the end of next sprint since then they will go through a round of manual regression tests that we do not have enough time to redo in the current sprint.
> Is it ok if the team decides pull more PBI into the current sprint if they
> think the work can be done within the current sprint
If a Development Team finishes all planned work in a Sprint Backlog and has attained the Sprint Goal then they may induct further items from the Product Backlog. However, they must have the agreement of the Product Owner and the commencement of this new work must not place the Sprint Goal in jeopardy. At the end of the Sprint, any undone work should be re-estimated on the Product Backlog.
> even if the plan is to not deploy the PBI until in next sprint?
That would not represent a valid plan. In Scrum, PBI's are not planned into a Sprint until the Planning Session for that Sprint. The ordering of items in a Product Backlog may indicate a potential order for inclusion in a Sprint but it does not constitute a plan for doing so.
In a recent post it was pointed out that if you have time left but you can’t or want to include additional PBI’s in the increment, you may consider improving your process, like:
1) Increase your cross-functional capabilities, like becoming more T-shaped team members
2) Inprove you DoD
3) Inprove your TDD or CI / CD capabilities
ok, I got it, thanks!
In this situation when the team got extra time at the end of the sprint, assume there is one big PBI with high priority that will probably not be possible to complete within the sprint and one smaller PBI with a lower priority that most likely can be completed within the remaining time of the sprint.
Can both these options (the small PBI or the big PBI) be considered to add to the sprint?
You should ask the Product Owner. The team will tell her that they can finish the small PBI within the Sprint. Maybe this gives the PO a reason to change the priority of this PBI.
Maybe, the high prio PBI can be refined into smaller PBI's. And maybe after prioritizing these items, some of them may be completed within the Sprint.
Talk to the Product Owner, lay out the options and agree with the PO on the right course of action.
This is also causing some discussions in our team. We started with Scrum this year and are in our 4th sprint. According to the scrum framework I fully agree with Jasper, but the developers still tend to do what has to be done from their point-of-view (which is not necessarily the first PBI.
I am drawing the following conclusions out of that:
I as Scrum Master should anticipate this situation well before and organize a meeting with the Product Owner to get more BIs for the team to work on in the remaining time.
The developers have to learn to request more BIs from the Product Owner and to concentrate on checking if the DoD is really met for the SBIs in the remaining time.
I am wondering if you agree on that.
Robert: Some context-setting about value..... Its important to keep in mind that Pareto's 80/20 law is well observable in many situations including software products -- Microsoft has found that the average Word user uses only 8% of the functionality -- Google has found that users prefer apps that "just do what they want" (i.e. just what they want and no more) -- Standish Group study found that 45% of software features are never used and 19% are rarely used. Overall, 64% of the features implemented in a sw app/product does not aggregate/contribute value to the product. Hence, teams (includes the PO) should always focus on the higher value PBIs and continue to invest in building T-shaped skills and practices that improve velocity and quality.
Given the above, the only reason that the team would work on a lower-priority PBI (assuming its also lower value) is fill the time remaining in the sprint. In actuality, this lower-priority PBI may rarely be used or never used by customers. Product owners typically don't like this, but the prior paragraph shows the largeness of the featuritis problem and the tremendous waste (MUDA in lean terms) from building low-value features.
In my perspective, the team should focus on the larger PBI to see if it can be further decomposed into smaller PBIs or pull the next highest-value sized PBI that can be delivered "done done" in the remainder of the sprint. If this is not possible, then the team can focus on a variety of kaizen - improvement opportunities - many of which Christaain has alluded to.