Questions of SCRUM. Approve or dissaprove? Why?
Dear All, I am trying to understand better the SCRUM procedures and try to understand the in the framework of the "agile manifesto" for a university subject. In order to complete my understanding, I would be wholeheartedly grateful if you would be able to give me your thoughts about the responses given to the following scenario and revise whether my logic on the APPROVE/DISSAPROVE decisions makes sense.
SCENARIO: We are already in Sprint 8 and towards the end of Sprint Planning, the Product Owner and the development team, have not agreed on which Product Backlog items should be assigned to the Sprint, although the which the Product Owner has made clear is the goal of the Sprint.
What actions as Scrum Master should you approve them?
1. Each team member start studying for separated the items of the Product Backlog. The Product Owner will be there available to solve manner doubts individual Once resolved the doubts the team is gather again for continue the Sprint Plan before start the Sprint. - Approve or dissaprove? Why? (I would APPROVE on the condition that this action doesn't compromise the ongoing Sprint, and also basing on the "agile manifesto")
2. If everyone agrees, Sprint Planning may continue even after the time allotted for this meeting has passed, until an adequate number of Product Backlog items are sufficiently understood to be able to make an estimate of how many they can do in the Sprint and then the Sprint begins. - Approve or dissaprove? Why? (I personally would DISSAPROVE as there would be a correlation between the duration of sprint planning, the items in the Product Backlog, and the duration of the whole Sprint in itself)
3. The team of development does the best he can in his estimate of how many items you can do for achieve the goal of the Sprint. Once it is the allotted time is over for the meeting, the Sprint begins and the team continues to analyze and break down tasks during the execution of the Sprint. - Approve or dissaprove? Why? (I would DISSAPROVE because during the execution of the Sprint the team should execute the alreadyplannified tasks, therefore, unless opperative related, the Team should focus on simply executing the plannified tasks and then revise the plannification on the next "evaluation/retrospective meeting" at the end of the Sprint)
4. At the next meeting of retrospective will be discussed because this has happened and what changes should be made so that it doesn't happen again. - Approve or dissaprove? Why? (I would APPROVE, as this is the normal procedure of SCRUM.)
Thank you very much for your advice.
Best,
Rob
This scenario doesn't make sense.
It sounds like this scenario is based on a commitment to a body of work. No one on the Scrum Team commits to a body of work. Instead, the commitment is made to a goal. The scope of work required to achieve the goal may change as the team does the work.
If the Developers and the Product Owner agree on the Sprint Goal, then the Developers have made their commitment for the Sprint. If the work is well-refined and understood, it should be easy to walk through the Product Backlog and identify whether a given product change is necessary for achieving the Sprint Goal. Regardless, it is entirely up to the Developers to create and maintain a plan to achieve the Sprint Goal. Since the Developers were able to commit to an achievable Sprint Goal, I would be curious how they were able to do so if they didn't have some basic understanding of the work needed to achieve that goal and the idea that they could complete that work within the Sprint.
None of those things, because the Sprint Goal isn't a selection of work determined by the Product Owner. The Scrum Guide makes it clear that the Sprint Backlog is a plan by and for the Developers, and the Sprint Goal is a single objective and a commitment by them. The first course of action for a Scrum Master would be to help everyone understand this.
A third for "none of the above". As @Thomas points out, the commitment for a Sprint is to the Sprint Goal. The work that is done can, and usually does, change while the Sprint progresses as the Developers learn more about the problem space and adapt to achieve the goal.
Empiricism is a basic premise of Scrum. It means that any work undertaken is used to learn about the next steps. Change is expected, valued and desired. Adaption is done constantly. It is hard for me to remember Sprints where the make up of the Sprint Backlog did not change during the Sprint.
...try to understand the in the framework of the "agile manifesto" for a university subject.
Let's look at the manifesto. Notice these statements on the first page?
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Now, go back to your original posting. Does what you describe follow the 1st and 4th statement from the manifesto?