By Raymond Shanley
I was recently discussing Scrum with some Scrum Teams, and one team was convinced that a certain ScrumBut was a better way to do things. This particular real life ScrumBut is to construct the Sprint Backlog so it has just the right amount of work for each specialist in the team based on how many story points each individual can deliver in a Sprint. Trying to argue that this approach is against the Scrum rules is not enough to convince people not to use it. At the time of the discussion I was unable to convincingly express why the approach is counter-productive. Afterwards I thought it must be that the problems caused by the approach are not immediately obvious. So I decided to run through an example on paper, which I will now present.
The product concerned is already a few years old and individual specialists have been responsible for parts of the product over those years. The team changed over to a Scrum approach in the past year. So due to the historical situation it is true that a specialist can finish an item in his or her component quicker than someone else. In order to change this situation, learning and knowledge creation would be necessary.
Before we continue let’s summarize the normal Scrum approach. The Team gives estimates for each item in the Product Backlog. The Product Owner then prioritizes the items according to value (and other factors can also be considered such as risk and dependencies between items). The Product Owner is responsible for generating highest value for the stakeholders in a sustainable way and generally wants to finish the highest value items first. The Team is responsible for figuring out how to deliver the items. There is a clear separation of responsibilities between Product Owner and Team. If there are specialists in the Team, the prioritization occurs independently of how much work these specialists are capable of handling in a Sprint.
Ken Schwaber gave ScrumButs a particular syntax: (ScrumBut)(Reason)(Workaround). So here is a formulation of the ScrumBut in this article using the standard syntax: "We use Scrum, but (we want individuals in the team to have just the right amount of work in his/her area of expertise) (so we construct the Sprint backlog according to individual specialist capacity)".
I will run through a concrete example for 4 Sprints first using the ScrumBut approach mentioned above and then using the normal Scrum approach. This is a simple example. It would be possible to construct a more complex example but the same basic problems would emerge so let’s keep it simple. In this example I assume that the Product Backlog prioritization does not change between sprints. If prioritization changes (like in the real world) the problems discussed here are at best only masked slightly.
Let's say we have 5 components in this particular product being developed by the Team. Each component is developed by 1 specialist and each specialist is capable of producing a slightly different amount of work per Sprint as in the following table. The team velocity is calculated as the sum of the individual velocities.
Now let's say our initial product backlog looks as follows. The letter represents the main component affected by a given story. I generated the order of the backlog by writing a list of the letters on a sheet of paper as randomly as possible. Then I wrote story points beside the letters also as randomly as possible (values between 1 and 3).
Summary of the stories on the Product Backlog so far:
ScrumBut Approach, Sprint 1:
If we now go through the Product Backlog and construct the 1st Sprint Backlog according to how much work each specialist can take on we get the following:
So the items that fit in the sprint are 1, 2, 3, 4, 5, 7, and 8, which gives a total 13 story points. Estimated velocity was 17. Item 6 did not fit in because developer C (the developer of component X) was already fully loaded. If specialists have spare time they can either do some other task outside the product scope or take on an item in their specialization lower down on the Product Backlog.
ScrumBut Approach, Sprint 2:
Summary of new items that entered the Product Backlog before the Sprint 2 Planning Meeting:
Below is the Product Backlog for Sprint 2, showing old items and the new items that were added before the Sprint 2 Planning Meeting. The last column shows whether the story made it into the Sprint Backlog or not (as usual, calculated based on individual developer capacity).
Note that item 6 is too big to be done by developer C in one Sprint. This could possibly be split into smaller stories. However, splitting it still does not alleviate the basic problem that developer C appears to have too much work, which creates a bottleneck in the system.
Note the pattern starting to appear, which is that higher priority items are being replaced by lower priority items in the Sprint.
The items that fit in this Sprint are 9, 10, 11, 12, 13, 15, 16, 17, and 20, which gives a total 14 story points.
ScrumBut Approach, Sprint 3:
Summary of new items that entered the Product Backlog before the Sprint 3 Planning Meeting:
Just as for the previous Sprint, here is the state of the Product Backlog. The final column shows whether the story made it into the Sprint Backlog (again, based on individual developer capacity).
The items which made it into the Sprint are 14, 19, 21, 23, 25, 28, 29, and 30, which gives a total of 13 story points. In this Sprint it is becoming clear that prioritization is hit-and-miss. Roughly every 2nd item needs to be replaced by a lower priority item.
Also, component X is clearly a bottleneck. At this point it might be possible to intervene and say developer C needs help and ask someone else to learn X. However, there are at least two disadvantages to this. First, it is a reactive rather than a proactive approach. It is at a late stage that developer C is getting help and he/she has so much work to do it will not be easy for him/her to take the time to show someone else the ropes. Secondly, this monitoring of potential bottlenecks requires additional administrative overhead. Someone needs to be constantly keeping an eye out for the problem occurring. With the normal Scrum approach you get this balancing automatically.
ScrumBut Approach, Sprint 4:
Summary of new items that entered the Product Backlog before the Sprint 4 Planning Meeting:
Same as for the previous Sprint here is the state of the Product Backlog. The final column shows whether the story made it into the Sprint Backlog (based on individual developer capacity).
The items which made it into the Sprint are 18, 24, 31, 33, 34, 35, and 36, which gives a total of 12 story points. In this Sprint more items were taken from the bottom half of the backlog than from the top half.
Scrum Approach, Sprint 1
Now let’s walk through the same example with the normal Scrum approach so we can compare the results.
The estimated velocity of the team is 17 but let’s just take on 14 story points to provide for cross learning. The top 7 highest priority items make it into the Sprint.
Scrum Approach, Sprint 2
This time we also take on only 14 points to allow for cross learning. The top 8 stories make it into the Sprint.
Scrum Approach, Sprint 3
This time let’s take on 16 out of an estimated 17 velocity as less cross learning is necessary as time goes on. In this Sprint the top 9 items are taken into the Sprint.
Scrum Approach, Sprint 4
For the final Sprint in this example let’s take on 16 out of an estimated 17 velocity. In this Sprint the top 9 items are taken into the Sprint.
Let's compare the items remaining in the Product Backlog at the beginning of Sprint 4 of each approach:
Conclusion
The example described in this article demonstrates that dangerous bottlenecks can develop if using the given ScrumBut approach. It also demonstrates that the ability to prioritize properly is diminished by the same approach. These are not the only problems caused. Other problems include:
- The so-called team is operating more as a collection of individuals. There may be no common sense of responsibility.
- One-piece flow may be affected. Parts of stories may be finished at the end of a Sprint and other parts missing.
- The team has no redundancy built in, which means if someone goes on vacation or gets sick there is a problem.
- Self-organization is effectively being killed. The team does not have a chance to decide itself the best way to deliver the functionality for a Sprint. This may also lead to motivation problems (intrinsic vs. extrinsic motivation).
- There may be an issue with trust: Does the Product Owner trust the team to deliver on a Sprint?
My advice is to avoid this ScrumBut even if it leads to reduced productivity (perceived or not) in the short term. Keeping this ScrumBut will lead to more serious problems in the long term.
