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

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.

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.

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.

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.  

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.

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. 

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?

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"

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).

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!

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.

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.