Rather than passively letting the product owner decide what she would like the team to work on during a specific sprint, it is our experience that the team would benefit more from the collaboration with the product owner if they have a more proactive attitude.

The team should take an active look at the set of stories prior to the planning and try to see whether they can derive an architecture vision from them.

Let’s assume that a recent workshop just concluded and a set of user stories has been identified as illustrated in Figure 7.1.

Figure 7.1. Inspecting the set of user stories for a central library system.

The team might take a quick look at the set of stories and be able to identify a high level architecture that would look like that shown in Figure 7.2.

Figure 7.2. Identifying the architecture intent for the central library system.

Then, using the common data element approach described in Chapter 6, “The Influence of Architecture Vision on Team Velocity and Software Quality,” the team will be able to divide the user stories among different rings as shown in Figure 7.3.

Figure 7.3. Dividing user stories among common data elements.

By continuing to further divide, the team may be able to split the user stories into smaller groups. This results in separating the data elements that would need to be created from the ones that would only need to be read, updated, or deleted as shown in Figure 7.4.

Figure 7.4. Further dividing the user stories among the common data elements.

At this point, there will be two options for the team to envision the release, either by horizontally slicing or vertically slicing.

Horizontally slicing means that the team can envision developing the software product by creating the foundation for the key data elements and entities across all the rings, starting from the core in the middle to the outermost ring.

In the case of a central library system, that could mean to lay the foundation for the book and patron entities first in release #1, and then reservation and location in release #2, as shown in Figure 7.5.

Figure 7.5. Organizing the release by horizontal slicing.

Next, by virtue of common data (and probably also of team velocity), release #1 can be split into two sprints. Sprint #1 will focus on the first part of the book concept while sprint #2 focuses on the first part of the patron concept.

The same approach can be applied to release #2, which can also be divided into two sprints, with sprint #3 focusing on the reservation concept while Sprint #4 puts the emphasis on the library location concept (Figure 7.6).

Figure 7.6. Divide the horizontal release into sprints.

Vertically slicing means the team could develop the software product by creating the foundation for all the data elements and entities, ring by ring. Going back to our central library system, this means that the team could first lay the foundation for everything that relates to the book concept in release #1; then, all the details for the patron concept could be in release #2, and so on (Figure 7.7).

Figure 7.7. Organizing the release by vertical slicing.

Next, we apply the same virtue of common data (and probably also of team velocity) to this second type of slicing. Release #1 (Figure 7.7), which focuses completely on the book concept, can be split into two sprints. Sprint #1 will focus on the basics of the book concept, while sprint #2 will focus its extension in terms of sub-types.

The same approach can then be applied to release #2, also shown in Figure 7.7. That can also be divided into two sprints (Figure 7.8), with sprint #3 focusing on the basics of the patron concept while sprint #4 focuses its extension in terms of patron sub-types, and so forth (Figure 7.8).

Figure 7.8. Divide the vertical release into sprints.

After a while, if you are concerned that you may lose track of all the release and sprint goals, you may want to organize them, along with their respective highlevel stories descriptions, using a matrix like the one in Figure 7.9.

Figure 7.9. Tracing sprint goals back to release goals (horizontal slicing).

In addition to the benefit it brings to the Scrum team for their release and sprint planning, the diagram in Figure 7.9 can be easily turned into a new and improved sprint backlog (Figure 7.10) to help both allocate teamwork assignments and track team progress.

Figure 7.10. A sprint backlog organized by sprints and by release.

Because we are talking about tracking team progress, we would like to make our position clear with regard to the so-called technical debts, defined as the accumulated amount of technical rework that will be necessary to correct the software design.

From experience, we have found that technical debts are an inverse relationship to software quality (Figure 7.11). Because technical debt hides the fact that a release is actually late, we are absolutely opposed to having it around.

Figure 7.11. The inverse relationship between technical debt and software quality.

If you are reporting that you are well on track to finish your sprint goals, yet you know that you have a heavy load of technical debt, you are not being honest with yourself and with your team members.

You should therefore strive at any cost to not let technical debt interfere with the tracking of your true project progress.

In addition to the helping hand an architecture vision can bring to the whole Scrum team in terms of release and sprint planning, there is one more concept the team could greatly benefit from: parallel software development (even within the seven-member Scrum team).

In other words, by organizing work around common data elements and the CRUD concept, you will be able to speed development by having small sub-teams (even within the current seven-member Scrum team) work in parallel on specific and self-contained user stories as shown in Figure 7.12. This, along with an effective continuous integration mechanism (using a tool such as Git), should allow the Scrum team to tremendously speed up their velocity.

Figure 7.12. Sub-teams developing in parallel.

Because more than one team is working together, you should modify the questions you ask during your daily Standup (still called daily Scrum).

In addition to the three well-known questions which are asked during these meetings:

We suggest that you add two more questions, which should allow the sub-teams to be easily synchronized:

To remind everyone on the Scrum team of their responsibility with regard to what they have to do, a summary is provided in Figure 7.13.

Figure 7.13. Collaboration for release and sprint planning.

Identifying architecture vision early on not only helps the team avoid velocity fluctuation but can increase software quality and lay down the foundation for a good application and data architecture.

In addition, it can help the development team have a more active, better collaboration with the product owner during the release and sprints planning meeting.

As a result, the Scrum team can increase both stakeholders’ business value and the robustness of their application while experiencing more satisfactory teamwork and effective collaboration.

Finally, using the common data architectural approach presented in this book can allow the team to speed up development by splitting the Scrum team into smaller size teams (which can be referred to as feature teams) that can perform work in parallel. This along with an effective continuous integration mechanism should allow the team to speed up their velocity or ability to finish their work even earlier than planned. With or without Scrum, this is something that has been the dream of software project managers and software managers for years.