Team discussing a project

Agile project management quiz - Part 2: Sprint backlog - Let the sprint begin!

Let's Quiz

Welcome to the Agile Project Management Quiz - Part 2. Scrum skills and your project management knowledge using real project examples test. It is about a specific project situation that we experienced ourselves and for which we had to find a solution.

Today's quiz describes a project situation from an agile project in which the Scrum process model was used. Scrum describes an iterative process for software developmentplanning takes place in sprints. Further information can be found in the quiz description for the first quiz.

In the first part of the four-part quiz series "Sprint Planning - All beginnings are difficult" was about planning the sprint. This takes place as part of a Sprint Planning Meetings in which the work packages to be implemented in this sprint are defined and planned. These Create user stories the Sprint backlog.

The stories in the sprint backlog must be specified in such a way that they can be implemented. This is because a user story can only be pulled into the sprint in Sprint Planning if it contains all the required information.

Sprint backlog - ready for implementation

Today's quiz is about this Sprint backlog. In Sprint Planning 1, we clarified which of the fully specified user stories need to be implemented in this sprint. Sprint Planning 2 shows how the stories can be implemented in concrete terms. Our sprint backlog was created from this.

At least that would be the ideal. However, it is often the case that stories that are not sufficiently specified end up in the sprint. so that concrete implementation planning is not possible. But how can this be prevented?

The Scrum Guide describes that a story should be "ready"to be selected by the development team in sprint planning. It is therefore of central importance that all project participants have a common understanding have of it, what "ready" means. To ensure this, it is helpful to establish a "Definition of Ready (DoR)" that defines exactly this. This is a list of criteria that are placed on user stories. The DoR is the Scrum team's requirement for the quality and information of a user story. The product owner ensures that this quality is maintained in the product backlog. The idea behind this is that vaguely described user stories cannot be included in a sprint, only those that correspond to the DoR.

Typical requirements in a DoR are

  • User story is described in a user-centered way
  • Acceptance criteria (functional and non-functional) are described
  • Dependencies are described
  • General conditions and requirements are described
  • All references for the implementation are available (e.g. CI guidelines, usability guidelines)
  • The business value is assessed
  • The estimate is available
  • Test cases are available

The practical case - a prototype for a trade fair

The Project situation originated in the context of condition monitoring and predictive maintenance. In the actual project, the team completed a project in four sprints. Prototype realized for a trade fair. As the prototype was to be presented at the trade fair, it was crucial to have a functional application available on the day of the trade fair. This meant that an application had to be completed in as short a time as possible which, although not yet ready for productive use, would present potential end users with the widest possible range of functions.

In the first sprint, the quality of the technical user stories was quite good after coaching of the product owners by doubleSlash, and the work progressed. You can see the current status in the table.

SprintSprint lengthSprint backlogTechnical/professional User StoriesSufficiently specified
11 week167/9All

In an extended sprint planning, user stories were suitably cut and open questions were clarified.

22 weeks3222/1010 technical user stories are not sufficiently specified, but accepted for the sprint.
32 weeks??The backlog is incomplete!
41 week??The backlog is empty!

The project is now one day away from the end of Sprint 2. Some of the post-specifications for the 10 accepted technical user stories are still missing.
The product owners declined another coaching offer to support them in writing the user stories for capacity reasons.

Questions:

Question 1What impact do the missing specifications have on the result of the current sprint?

Question 2: What risks do you see for the project result?

Question 3: What can the project manager do to bring the project to a successful conclusion?

For this case, too, there is no the right solution. Please send us Your answers per Contact form or post a comment under this post, then we will gladly send you the Sample solutionwhich is our recommendation for dealing with the project situation, by mail back. We look forward to your ideas!

 

You can find more agile project management here

 

Here you will find parts 1, 3 and 4 of the project management series:

Part 1 of the PM Quiz - Sprint Planning - All beginnings are difficult

Part 3 of the PM Quiz - Reporting - Is our project successful?

Part 4 of the PM Quiz - Sprint Review - What have we achieved?

 

HIer free of charge our Magic Estimation cards for efficient Scrum effort estimation

Order our Magic Estimation cards free of charge here

 

Sabine Rossbach

About ME

All contributions from Sabine Rossbach

Learn more

Further information on our website and in our newsletter

Arrow up