10

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?

Improve this question
13
  • This third-party licensing limitation is a fact of life and should be used as the reason to reprioritize stories and cancel this sprint and start a new one. As much as everyone may want a particular feature/story done first, it's just not going to happen and it makes no sense for everything to wait. Swarming is one solution that a Scrum Master should suggest, but the team should decide whether or not to do it. I don't think there is anything in the laws of Scrum that would prevent this.
    – JeffO
    Jun 14, 2016 at 17:14
  • @JeffO We tried to push back a little and basically got a lecture about ignoring the product owner's wishes. There was some talk about using Scrumban at some point in the past and my scrum master was very opposed to that because the PO did not have control. It is part of our particular dysfunction that pointing out that swarming is not appropriate in this situation is answered by swarming even more people.
    – Ukko
    Jun 14, 2016 at 19:57
  • Why isn't the tester working on their tests and/or test plan? Testing is one activity that should be started well before the code is ready.
    – Bryan Oakley
    Jun 14, 2016 at 20:20
  • @BryanOakley The answer my scrum master gave me was because they might have a good idea and cross training. Personally, I see it as a waste, my scrum master feels like we should avoid skill silos. My thought was we are experts in our areas, but he says the goal is for us to be able to jump in and help each other.
    – Ukko
    Jun 14, 2016 at 20:39
  • 1
    @Ukko: that's actually an OK answer. The main goal is to make sure they aren't literally just doing nothing. As long as they are part of the process from the beginning of the sprint to the end, that's all that is important. Too often testing is left to the end of the sprint.
    – Bryan Oakley
    Jun 14, 2016 at 21:05

4 Answers 4

Reset to default
7

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.

Improve this answer
4
  • I will totally point out Individuals and interactions over processes and tools. I am totally in favor of pulling in work, but that is very frowned on, again because we are going against the PO's priorities. The funny thing is that seems to be a theme that is coming up as I describe this.
    – Ukko
    Jun 14, 2016 at 20:11
  • 2
    @Ukko - priorities are priorities, not a queue.
    – Telastyn
    Jun 14, 2016 at 20:13
  • 1
    @Ukko: The official Scrum way to deal with that problem is to talk with the PO if they are willing to re-prioritize some work to get the complete backlog done sooner. I still have to meet a PO who isn't willing to work with the team in such a way.
    – Bart van Ingen Schenau
    Jun 15, 2016 at 6:52
  • @BartvanIngenSchenau mentioning the PO rings a bell. That is one thing that is not well defined here. We don't have a good PO role in the organization, there is a group of BAs that play the role of POs but they are not the real POs. In this case the BA is getting lots of pressure from management on this specific functionality, and she was kind of afraid to have us touch a "low priority" story.
    – Ukko
    Jun 15, 2016 at 15:16
3

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.

Improve this answer
1

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.

Improve this answer
0

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)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.