Pre-Sprint Item Analysis and Idling during the Sprint

during the sprint planning, the development team should already know most of the details of the item, in order to estimate it and add to the sprint backlog.

Product Backlog refinement is the art and science of making work ready for Sprint Planning, meaning the Developers are confident it can be Done in a Sprint. By the time they enter Sprint Planning that work should therefore have already been estimated. Any analysis which might be necessary to provide them with this confidence should also have been performed.

What should the idle members do during the sprint?

Recognize that they have made a joint commitment, are collectively accountable as Developers for the work they do, and hence are unlikely to have good reason to be individually idle. They may collaborate by:

• helping each other to acquire new skills to minimize hand-offs, and/or
• by improving joint focus so work items are completed early and often, with minimal delay between remaining hand-offs and minimum batch sizes.

There will be no team without such teamwork.

1. Although the task is to deliver the MVP during the sprint, there should be some analysis involved to provide a greater detail to the items of the backlog (especially when you are creating a product with clear, pre-defined processes). When is such analysis done and who is doing it? Product Owner alone pre-sprint or the business analysts during the sprint? Because during the sprint planning, the development team should already know most of the details of the item, in order to estimate it and add to the sprint backlog

Backlog refinment can be done in many ways. These are some of the places I handle them.

1. With stakeholders and the productowner (outside the sprint)

2 during the sprint with the team or part of the team for upcomming items

3 During the sprint planning with the team 

4 and during the sprint for PBI's that are in the sprint but need some more clarification.

What should the idle members do during the sprint?

Find ways to help the team to achieve the sprint goal.

For instance, in order to have a cross-functional team, the testers should be in the team as well, they cannot perform their tasks till programmers will do their work.

Yes the test task should be done by the team. but the development of the testcases also so and this can start at the same time of even before the developer starts. The sqill of testing is more then testing the software. it also consist of analysis choosing a test method and writing the test scripts in my experience is the executing the test only 20% of a testers work.

Although the task is to deliver the MVP during the sprint, there should be some analysis involved to provide a greater detail to the items of the backlog (especially when you are creating a product with clear, pre-defined processes). When is such analysis done and who is doing it? Product Owner alone pre-sprint or the business analysts during the sprint? Because during the sprint planning, the development team should already know most of the details of the item, in order to estimate it and add to the sprint backlog.

Product Backlog refinement is the name for the activity where the Scrum Team makes the Product Backlog Items ready for selection in a Sprint Planning.

The Scrum framework has minimal rules about what it means for a Product Backlog Item to be ready for selection - it needs to be something that the team believes is achievable within a Sprint. In my experience, teams often want Product Backlog Items that are smaller - things that can meet the Definition of Done in two or three days, at most. The Scrum Guide does contain some examples of attributes of a Product Backlog Item that may come out of refinement: description of the work, details, size.

The whole Scrum Team participates in Product Backlog Refinement. Scrum only recognizes three roles: Product Owner, Developer, and Scrum Master. The Product Owner and Developers are the primary participants in refining the work. The Scrum Master may facilitate refinement activities. Anyone who has relevant information and can participate in refinement. There's also no set way to carry out refinement - I've worked with several teams and each had their own ways of performing refinement.

I'd also add that the team should not be waiting for Sprint Planning to estimate and add to the Sprint Backlog. If the team is estimating (and estimation isn't required), then that would be a part of Product Backlog Refinement activities. It may be impossible to avoid some refinement at Sprint Planning, especially if the Product Backlog has changed at the Sprint Review or between the Sprint Review and Sprint Planning session, but it shouldn't be the norm.

In Scrum the members of development team should be fully dedicated to the current sprint. What should the idle members do during the sprint? For instance, in order to have a cross-functional team, the testers should be in the team as well, they cannot perform their tasks till programmers will do their work. Should they be idling if they cannot contribute anyhow toward the sprint goal.

There are a few options. But I will say that being idle isn't necessarily a problem. Having some slack is a good thing, in case there is unexpected work. However, slack doesn't necessarily mean that the person is doing nothing. There are probably valuable things that could be done: paying down technical debt, learning new skills, refinement of the Product Backlog, organizational overhead work (company-mandated training, for example).

Using the example of testers, I don't think that it's true that they cannot perform their tasks until the programmers are done. They should be able to build black-box test cases against Product Backlog Items, for example. But they can also perform test case maintenance and improvement, learn development skills to be able to develop Product Backlog Items, build and maintain a test automation framework, or pair with developers to improve developer testing skills and get early visibility into work, just to name a few examples.

Should they be idling if they cannot contribute anyhow toward the sprint goal.

A number of good examples have been given about what Developers can do to be productive, whether it be working towards the sprint goal, towards reducing tech debt, or any number of activities which benefit the organization as a whole.  But I would like to point out that I find it common, maybe every second or third sprint on average, on the teams I work with that a developer (lower case "d" in this case, the folks who write code for a living) will come to the Product Owner or myself (Scrum Master) when they've completed the stories they've been assigned asking for more stories to be pulled into the sprint.  Very often we have to say no as the additional work would not be completed by the testers by the end of the sprint.

The point being that I find it fairly common for this "idleness" topic to come up from any of the Developers on the team.  And that it's likely something you'll deal with regularly as you work as a Scrum Master/Product Owner.  I find it helpful to keep in mind of all the "other" things they can do to remain productive for when these conversations pop up.

Good luck!