Scrum and swarming non-parallelizable tasks

Question

My current scrum master is a true believer who is not willing to budge on the official forms of scrum. I don't want this to sound ranty, I am really asking about the orthodox solution to this issue because I have been successful resolving issues with him in the past by recasting things in official terms.

The current example of a recurrent issue we have is that there are some ordering dependencies between some of our stories. (In particular, part of the development uses a third party program which we only have a single seat licence for.) There are some necessary setup tasks that are associated with this that have been gathered into a "Setup Story" and then we have 6 tasks that can follow in any order.

The issue is that for the current sprint we pulled in the Setup Story and one of the follow on stories, at which point I said that we cannot take any more stories in this group, even though our sprint is less than half-full. There are unrelated stories on the backlog that were prioritized lower than this group that I suggest we could bring into the sprint. However, these were all prioritized below the stories in this group. At this point the scrum master stated that we should swarm the "Setup Task" and get it done faster, this is a conflict we have had before and he has dug his heels in.

So, for the first half of this sprint two developers and a test resource are watching me work through the external vendor's configuration website, downloading resources, and shuffling certs around. All the while I know that we have a release coming up in three sprints and we could get almost the whole backlog the PO would like done, but we won't because no work is being done on those tasks while everyone sits watching (er, swarms) the setup task for the highest priority story.

My scrum master says that our only concern is completing the stories we accepted for the sprint. Which I understand, but I feel like we are failing the larger organization by not communicating the "bad bin packing" that the prioritization we received from the product owner is causing.

So, how officially are issues of dependencies between stories and inherently serial stories handled by the methodology?

Answer 1

So, how officially are issues of dependencies between stories and inherently serial stories handled by the methodology?

As with anything else in Agile: Individuals and interactions over processes and tools

If your process isn't serving you, then you mold it into something useful. For this, I would pull in lower priority stories (or some technical debt/personal growth that maybe isn't visible in the backlog) until the pre-requisite is cleared. Assuming of course that you've done your due diligence and it really is a hard and fast pre-requisite. For a lot of things, interfaces and mocks can unblock work until the real thing is ready.

Answer 2

One of the features of kanban, which I believe bleeds over into scrum, is that the process as a whole optimizes for the team, not the individual. In other words, it's no sin if someone on the team is idle for part of the sprint.

If the team as a whole chooses X story points, it really doesn't matter (to the stakeholders) whether one person did all the work or if the work was equally divided. So, if the product owner is happy with the number of points that is brought into a sprint (and this is the product owner's call, not the scrum master!) then that is all that matters.

Of course, that being said, if some team members are not directly involved in the first story, they can be busy writing tests, or doing whatever they can on the other stories.

As a final note, the scrum master has little business "digging in his heels". The scrum master should be working for you to remove barriers to productivity, not set barriers up. If the team as a whole feels they can pull in another lower priority story, that is a decision for the team to make; the scrum master has no final say in the matter.

An exception can be made if the team is young and still learning scrum, but if the team is mature, the whole point of scrum is to empower the team rather than the managers.

Answer 3

The way I see this, you've got two different issues:

1. How to optimize your team's productivity.
2. How to order the product and sprint backlogs based on dependencies.

For your team's productivity, I can sympathize with your Scrum Master: I've found, due to human nature, that most people want to keep everyone busy, rather than optimizing the entire team. Being busy does not equal productivity. Idling may be the best thing for a team member to do at a given time.

On the specific matter of the setup task: this sounds like something that should be automated. Given your write-up, if I were working with your team, I'd want to spend some time figuring out what is going on with this setup process that is both time-consuming and blocking, since it sounds like a prime candidate for improving the team's effectiveness.

I would also hope, at a minimum, that you are not the only person on the team who can do this. If you have a day off, I would hope the team has other people who can handle this bottleneck process. Swarming might be a chance to ensure that multiple people learn how to do this.

Assuming that you have an unavoidable dependency between Product Backlog Items (PBI), I would consider all dependent PBIs as blocked until the the blocking dependency is addressed. In general, this means leaving the blocked PBIs out of a Sprint. Since you have control over the blocking dependency, I can see bringing the dependent PBIs into the sprint, but that seems like a risky move. In Sprint Planning, I would generally only expect to consider PBIs that are not blocked.

Bottom line, though, is to find what works best for delivering valuable, tested, working software as effectively as possible.

Answer 4

The number 1 rule to building your sprint backlog (adding your product backlog items, or PBIs) should be to follow the basic INVEST principle:

1. Independent: The PBI should be self-contained, in a way that there is no inherent dependency on another PBI.
2. Negotiable: PBIs, up until they are part of an iteration, can always be changed and rewritten.
3. Valuable: A PBI must deliver value to the stakeholders.
4. Estimable: You must always be able to estimate the size of a PBI.
5. Small: PBIs should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
6. Testable: The PBI or its related description must provide the necessary information to make test development possible

It seems as though your Scrum Master is forcing the team to break the first rule, all stories in a sprint should be independent - what do you do if you are blocked on that one story that you need to complete to get any other stories closed? You will likely fail the sprint in this case.

I do agree that swarming/pair programming is a good way to collaborate and share knowledge in the team - but if there is no need to swarm on something like this, then I would stick to your guns and quote INVEST :)

Copied from Wikipedia: https://en.wikipedia.org/wiki/INVEST_(mnemonic)