Devops for Growth

Feature Bazar: Scrum teams pitch which Product Backlog items they want to work on

At a Feature Bazar, the Product Owner presents the new features. Afterward, the teams select the topics they want to work on. Each feature should be chosen by at least two teams. By assigning teams to the features, the initial overview for the Cross-Team Refinement is quickly created. 

Update the Cross-Team Refinement Board daily

Just as the Nexus Sprint Backlog is updated daily in the Nexus Daily Scrum when new dependencies occur in the current Sprint, the Cross-Team Refinement Board should also be updated daily. Only when the Cross-Team Refinement Board represents a real-time picture of all known dependencies, is it easy for the teams to resolve them.

Representatives of the teams participate in the Cross-Team Refinement

Inviting all members of the Scrum teams to the Cross-Team Refinement is often neither practical nor necessary. In order to proceed in a focused manner, only representatives of the individual teams should be invited. Scrum teams select their representatives based on the work to be refined. Domain and technical knowledge are good selection criteria to quickly identify appropriate team members. 

Alternate team and cross-team refinement

In cross-team refinement, cross-team dependencies are uncovered, eliminated, and forecasts are made about which team is likely to work on which Product Backlog item. In contrast, in team refinement, Product Backlog items are broken down, detailed, and estimated. Often, new cross-team dependencies are found in the team refinement. To eliminate these dependencies as quickly as possible, it makes sense to constantly alternate team and cross-team refinement. 

Cross-team refinement should be a regular meeting

To reduce unnecessary scheduling, cross-team refinement should always take place on the same date. For me, it has proven successful to reserve at least one afternoon a week for the Cross-Team Refinement.

Not just visualize dependencies, but eliminate them 

Visualizing dependencies in the Nexus Sprint Backlog to make them transparent is only the first step. The critical step is to consistently eliminate dependencies between teams. Ways to eliminate dependencies are: Interchange features between teams, break down Product Backlog items, build up missing knowledge in the team and change the likely possible processing order.

Nexus Integration Team provides awareness of cross-team dependencies

In their daily teamwork, Nexus Integration Team members constantly keep an eye out for potential dependencies. If new dependencies are discovered, they encourage team members to make them transparent at the Cross-Team Refinement Board and look for ways to eliminate them early. In the long run, this creates awareness of the impact of cross-team dependencies within the teams. 

Don't fall into the waterfall trap: Don't plan too far in advance, focus on the next sprint

Software development is complex. There are unknown unknowns. Therefore, it is impossible to anticipate all dependencies in advance, no matter how long refinement and planning are done. To avoid wasting time, the nexus should only refine the next one to three sprints in advance. 

Trying to anticipate the implementation sequence of the Product Backlog is like a faucet: the further we turn it on, the closer we are to the waterfall. 

1. Extract a smaller story by focusing on a particular user role or persona. (“Prioritize your users first, then your user stories.” — Jeff Patton) E.g.: “first time user,” “social networker,” “my mom,” etc.
2. Extract a smaller story by substituting basic utility for usability. (First make it work, then make it pretty.)
3. Extract a smaller story by splitting on CRUD (Create, Read, Update, Delete) boundaries.
4. Extract a smaller story by focusing on distinct scenarios, such as the “happy path” (main success scenario) vs. alternate (exception) flows.
5. Extract a smaller story by focusing on a simplified data set.
6. Extract a smaller story by focusing on a simplified algorithm.
7. Extract a smaller story by buying some component(s) instead of building everything yourself.
8. Extract a smaller story by discarding technologies that increase hassle, dependency, and vendor lock.
9. Extract a smaller story by substituting some manual processes for full automation.
10. Extract a smaller story by substituting batch processing for online processing.
11. Extract a smaller story by substituting generic for custom.
12. Extract a smaller story by reducing supported hardware/OS/client platforms.
13. Extract a smaller story from the acceptance criteria of another story.
14. Extract a smaller story by substituting “1” for “all.” (NOTE: Look for implied instances of “all,” as the word often won’t be written explicitly.)
15. Extract a smaller story by scanning for keywords such as “and,” “or,” periods, and other kinds of separators.

There are many techniques for splitting stories. Here are some of the more useful ones.

Split by capabilities offered

This is the most obvious way to split a large feature. Look at the different capabilities being offered and split each one into its own story. For example, the capabilities “sort and search” may each be its own story. Splitting further, each way of sorting or searching may be its own story.

Split by user roles

Administrators interact with a system differently from normal users. Teachers interact with instructional software differently from students. By defining the different roles in your system, you can split features and stories to address the unique needs of each role.

Split by user personas

Even in the same role, different people interact with software in different ways. A power user wants lots of keyboard shortcuts. A casual user may want a lot of intuitive, hold-your-hand forms of help. Handicapped users may need very different ways of interacting with the system, even though they are doing the same tasks as other users.

Split by target device

You can’t assume that users are interacting with your system using a standard computer. Various smartphones and IoT devices need to be considered in your stories. Splitting stories by device provides a more natural experience for your users.

Splitting stories lets us separate the parts that are of high value from those of low value, so we can spend our time on the valuable parts of a feature. (Occasionally, we have to go the other way as well, combining stories so they become big enough to be interesting.) There’s usually a lot of value in getting a minimal, end-to-end solution present, then filling in the rest of the solution. These “splits” are intended to help you do that.