Stage 2 of the Product Backlog

If an entry has been transferred into the second stage by the Product Owner Team , the analysis team or the analyst begins to describe this entry in detail.

Estimation tasks and technical detailing are done by the Team and must therefore be specified as Tasks for Sprints. These Tasks will be earmarked for the next Planning Meeting. So that the Sprints remain plannable, these tasks are given time windows (fixed maximum effort for a task). Scrum has the concept of “Refinement” for working on the improvement and organization of the Product Backlog. In order to do this, the Team should devote approx. 10% of its time as to understand the Items in the Product Backlog and improve them together with the Product Owner Team.

Diagram 26 describes the content and main components of the second stage.

Scrum Product Backlog Stage 2

Diagram 26: Product Backlog Stage 2

In Stage 2 of the Product Backlog, Items come exclusively from Stage 3. Should major changes occur to the Items, it may also be possible to put an Item from Stage 1 back into Stage 2. This should however only happen in exceptional circumstances.

All elements of this second stage are therefore initially Tasks for the analysis team or the analyst. The task of the analyst is to describe the functional requirements by means of use cases and, when graphical user interfaces are involved, also to describe these Items with Screens.

Functional requirements are described by the requirements submitter with “Use Cases”, leaving no room for interpretation. This can simultaneously be read and understood by specialist and technical employees. The effort for the development team to technically translate a text is no longer required. The generated documentation represents Use Cases graphically and formulates them in written form.

Graphically represented Scrum use case

Table 5: Graphically represented use case

Table 5 describes the minimum features that a use case must contain. The table can be supplemented with additional features. This is however a project-specific decision.

Through the detailed course and the conditions, the submitter of the requirements determines how this requirement can be tested. From this, the developer can then directly deduce his own technical tests. From the total of all of these use case descriptions, the requirements submitter can generate his acceptance document.

The screen designs are subject to the general guidelines for the project’s defined graphics which have been formulated at the beginning of the project or have been integrated into the corporate design of a company or enterprise software.

By defining the screen design, the requirements submitter has the possibility to examine and test his formulated requirements early on in the project. For a first test, the so-called Paper-Based-Design is particularly suitable. This means that during the specification of requirements, the analysis team or the analyst draws, with pen and paper, screen sketches of the functional requirements discussed and can then visualize the first ScreenFlow (flow of the functions on the screen).

Furthermore, all of the requirements, including non-functional requirements, are extended by a Work Breakdown Structure (WBS). The WBS divides Items into small, manageable and testable packages so that they can be estimated by the Team. The WBS is mainly created by the Team. In the Planning Meeting, the Team has the task of drawing up an implementation plan.

There is an analogy in Scrum on the Commitment or Forecast at this step:

A chicken proposes a business idea to a pig. The chicken wants them to open a breakfast restaurant together. It should offer eggs and bacon. The pig declines because for the chicken it would have been easy since it is only “involved” by laying eggs; the pig however is “committed”, since it must sacrifice itself for the bacon.

It is therefore necessary in Scrum that a statement about the effort is only allowed to be carried out by those who are also “committed” – this is the Team.

In the recent past however, only the term Forecast was used because in practice, the Commitment of the Team was often abused by overtime and the Team ceased to seek dialogue with the Product Owner if there were any problems.

The following graphics, Diagram 27 and Diagram 28, show the possibilities of the graphical portrayal of the contact form, the use cases or the screen description.

Scrum Product Backlog Stage 2, UML Use Cases

Diagram 27: Product Backlog Stage 2, UML Use Cases

This diagram was created with YAKINDU requirements. The Use Cases are shown graphically to give a better overview and also include additional details, as described above.

Scrum Product Backlog Stage 2, Screen Design

Diagram 28: Product Backlog Stage 2, Screen Design

This diagram represents the technical wishes in great detail and is thus an accurate guide for the developers. Should any changes arise during development, then this graphical representation can be used as a basis for discussion. The graphical representation of the requirements is free of interpretation and helps the submitter of the requirements and the developers with the implementation.

An example of a WBS is given in Diagram 28.

Scrum Product Backlog Stage 2, WBS

Diagram 29: Product Backlog Stage 2, WBS

The WBS includes the main tasks and its detailed definition. As described in the section “Planning”, each task here includes a three-point estimate for the situations Best Case, Average Case and Worst Case. The estimator(s) record their adopted three cases here. The PERT-Value (Program Evaluation and Review Technique), i.e. the Beta-Distribution, calculates the estimated effort. By means of the variance, an overview of the estimation deviation is given which can then be reacted to separately by the Team. By taking the standard deviation into account (see section “Real days and the Beta-Distribution”), the accuracy of the estimation can be improved.

When all of the duties for detailing and documenting the second stage of the PBL are completed and all of the Tasks have been estimated, they will then be prioritized by the Product Owner Team. After being checked for completeness, the Items with the highest priority are shifted by the Product Owner Team into Stage 1 of the PBL.

Switching into Stage 1 equates to an assignment for the development team. These Items are then planned into the Team’s next Sprint Planning Meeting according to priority and are then implemented.