Skip to main content

When someone from the team finish the planned sprint work and we still have few days left to close sprint

Last post 11:21 am May 16, 2023 by Ryan Kent
12 replies
01:36 pm May 11, 2023

When someone from the team finish the planned sprint work and we still have few days left to close sprint and he really can't contribute in work which is still not finished and other team member is working on it. Then he starts working on the priority ticket from next sprint.In that case is it good to pull the ticket in current sprint? 


02:34 pm May 11, 2023

My opinion: Scrum team, developers in particular should address the issue with no delay.

Of course this should be addressed at retrospective; this situation (this should not be treated like a problem, just a situation) means that team does not estimate PBI well enough and doesn't pick enough work for the Sprint at the Sprint planning

The lesson should be simply used for upcoming Sprints, and eventually, within time, developers will certainly learn to to create better fit Spring backlog and better roadmap to achieve Sprint goal.

The whole situation is quite typical for a young Scrum team, and  it is a beneficial element in maturing and learning from experience.

 


02:44 pm May 11, 2023

Before picking up anything from the Product Backlog, questions like these should be thought through as a team:

  • Has the team's commitment to the Sprint Goal been met? If not, why isn't he assisting his teammates with tasks such as pairing, code reviews, testing, documentation, etc.?
  • Will at least one valuable and useful Increment be completed in the Sprint and ready for inspection at the Sprint Review?
  • Have prior improvement items from the last Sprint Retrospective been completed?
  • Is there any lingering technical debt in the product Increment that could be cleaned up?

In a world of complexity, things change quickly. Working on something before the next Sprint starts may be a waste.

 


02:53 pm May 11, 2023

When someone from the team finish the planned sprint work and we still have few days left to close sprint and he really can't contribute in work which is still not finished and other team member is working on it. Then he starts working on the priority ticket from next sprint.In that case is it good to pull the ticket in current sprint? 

You would have evidence that you might not really have a team at all, because the ability to demonstrate teamwork is compromised. One Developer cannot help another complete the work they jointly own and have in progress.

We have a saying in Scrum: stop starting, start finishing. It's important to limit work in progress so team focus can be applied. That's the issue to resolve.


07:42 pm May 11, 2023

Why doesn't that individual do things that can contribute the team without introducing more work in the Sprint?  For example, they could review the Product Backlog and provide some refinement activities based upon information discovered during the current Sprint.  Or they could discover technical debt, such as needed upgrades to infrastructure, that can be added to the Product Backlog for refinement and future consideration.  Or maybe they could study a new technology or an upgrade to existing technology so that the information can be shared with the rest of the Developers. 

There are many things that a single individual can do that will benefit the Scrum Team that does not involve adding work to the existing Sprint Backlog.  


08:33 pm May 11, 2023

Daniel gave an excellent example of WHAT the developer can do, but there is other more important aspect-no one can ORDER a developer to do this things.

Its a scrum team, and developers in particular  who should learn by the failures how to sort out such things, and to learn it by own way-which makes them strong.

When addressing any problem in Scrum and Agile in general, it always worth remembering that whole philosophy of Agile comes from the mentality where problem is not only the impediment, or deviation, but also an asset.

Because any problem which is identified, talked about and later solved is valuable lesson which cases higher efficiency

Basically Scrum is a environment where not only everything what does not kill you certainly makes you stronger, but luck of mistakes and failures which can potentially kill you, is, ironcially most dangerous thing...

So what's happened in this Scrum team, the reaction, the discussion here and possible further search for solution within a team will be a  gain not a loss.

The enemy of Scrum is stagnation and luck dynamics, not the conflicts and mistakes

I repeat, problems, conflicts, and mistakes can also be your friend.


01:05 am May 12, 2023

I agree with what everybody said. The points mentioned above are the correct way. 

However in our team when people are done and cannot help, the top priority from the next sprint is pulled in, even if to make a good start. One work with people and people are often eager to continue with the work. I understand there can be disagreement on this. Should you put the ticket in the current sprint? I would say discuss this in the team and see what works the best for the team. 

 

 


01:28 pm May 12, 2023

One thing has not been mentioned yet: "he starts working on the priority ticket from next sprint"



How does the developer know that item will be in the next Sprint?


05:26 pm May 12, 2023

How does the developer know that item will be in the next Sprint?

Because big number or organisations who run a  project referred to as "Scrum" are having a system of operations where management or CEO decides in advance, what should be in product backlog, and what should be put on for a next Sprint

Why are they choosing to add a Sprint planning, Daily Scrum, Review and retrospective to their business agenda, and to use Jira for the project software.is another story. Most often it is happening because superior manageùent told them to "change to Scrum" or someone in the management had a vanity whim, and decided to "try this new popular thing everyone else has"

But in reality it a usual good-old way of doing business, where team leader is called "scrum master", and sales manager is called  "product owner". Nothing else

Its called "zombi scrum"


11:18 am May 14, 2023

However in our team when people are done and cannot help, the top priority from the next sprint is pulled in, even if to make a good start.

The “Next Sprint” doesn’t exist until the end of Sprint Planning. Pre-planning a Sprint means we are not making decisions based what is observed through empirical learning. It means we are not collaborating with our Stakeholders at Sprint Review. Consider that coming out of Sprint Review the Product Backlog may be updated and new priorities may be agreed upon.

Perhaps you mean just pulling from the top of the ordered backlog.

In any case, consider that the team’s choice to start that work, “even if to make a good start” carries impact

  • Current Sprint Goal and/or useful Increment may be compromised in current Sprint (split focus)
  • If product priority changes as a result of learnings from Sprint Review, started work may be dropped and any time spent on it wasted
  • By starting work outside of the Sprint Goal, we are now potentially influencing what the focus of the next Sprint might be
  • Capacity is already impacted for the next Sprint, which may compromise the team’s ability to achieve the next Sprint Goal
  • Team may want to focus on started work, rather than the next Sprint Goal, even if they are not aligned

Not saying that they can't or shouldn't, it is up to them to decide. I just think it is important to consider the above. 

The options presented by Chris may be better choices as they are focused first on the current Sprint Goal and Increment and less influenced or impacted by the outcome of Sprint Review (improvements still need to happen etc).


04:04 pm May 15, 2023

I personally am a fan of what @Ryan told just above because I think this is really the essence.

 

I have a question for you @Ryan:

The “Next Sprint” doesn’t exist until the end of Sprint Planning. Pre-planning a Sprint means we are not making decisions based what is observed through empirical learning. It means we are not collaborating with our Stakeholders at Sprint Review. Consider that coming out of Sprint Review the Product Backlog may be updated and new priorities may be agreed upon.

How would the Scrum Team/Product Owner choose the topics of the Product Backlog Refinement during the Sprint, if not pulling from an ordered Backlog?

Based on the above statement, it seems to me that it could be "better" to defer this activity (at least the big part of it) after the Sprint Review (whereas it is described as an "ongoing activity" throughout the Sprint) - which actually would just be the Sprint Planning.

Please correct me in case I misunderstood anything about it, thank you!

 


10:59 am May 16, 2023

Hi Alessio,

My intention wasn’t to imply that there shouldn’t be an ordered backlog or that refinement shouldn’t occur. Both of these are important, and having ordered backlog items in a ready state for Sprint Planning is certainly beneficial.

I was focused on the “top priority from the next Sprint” part, which is a different thing. This reads like Sprints have been predetermined. 

The top of the backlog may contain product backlog items that may be pulled into the next Sprint or the order of the Product Backlog may be impacted by the outcome of Sprint Review or through any other empirical learning. We won't really know until Sprint Planning occurs.

To lift a quote from Chris...

In a world of complexity, things change quickly. Working on something before the next Sprint starts may be a waste.


11:21 am May 16, 2023

Based on the above statement, it seems to me that it could be "better" to defer this activity (at least the big part of it) after the Sprint Review (whereas it is described as an "ongoing activity" throughout the Sprint) - which actually would just be the Sprint Planning.

Interesting idea. Let's explore...

I can't think of anything within the Scrum Guide that says you couldn't approach it this way. There is little guidance on when and how you conduct refinement. As you mentioned, it is referenced as an "ongoing activity" and there are only a few references to refining within the guide...

- The Product Backlog is refined as needed

- The Scrum Team may refine these items during this process (process meaning Sprint Planning)

- acquire this degree of transparency after refining activities

- Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items

You could conceivably do refinement during Sprint Planning. I think that your Sprint cadence, domain of work, dependencies etc. would definitely be influencing factors. I am imagining a scenario where Sprints are only a few days long. It could make sense to use Sprint Planning for refinement activities rather than take up time from those few days. For longer Sprints, say one month, it is a long time to wait for refinement activities to occur so I don't see this working as well.

Curious to know if anyone has tried this or has other thoughts to share on it.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.