2

Our team has decided to develop using BDD/TDD in an effort to become the Agile team we're supposed to be. Vertical slicing appears to be an important part of agile working and gaining the quick feedback we require, although I think we're going to hit a problem when we start dividing our PBI tasks between us.

We are creating a distributed system with multiple web services and a single page app. Take these two user story examples, each which represent a PBI:

  1. As a user I want to be prompted to enter my smartcard PIN so that I can login
  2. As a user when I enter my smartcard PIN correctly I am taken back to the system so that I can use the system's modules

The problem comes from the tasks that are required for each of these PBIs/user stories to be completed, as some are shared.

For example, a business requirement of our organisation is that all requests must be logged. So the acceptance criteria for these PBIs (and just about any other we will have) must contain a call to an audit service.

So with the way we plan on using vertical slicing I can imagine two devs both writing the same part of the audit service that does the logging, including the tests that will drive the implementation, effectively wasting one developer's time.

Also there's the element of remembering which PBI included some functionality that will be required in others.

How do you organise in order to avoid this? Is this an inherent problem with vertical slicing? It seems this would be less of a problem with horizontal slicing.

  • And PBI stands for? – Fabio Jan 23 at 5:37
  • Sorry. Product backlog item. We're meant to be following Scrum. – Lee Jan 23 at 8:02
5

In my experience doing development in this way, there are a few places this should get caught:

1) It should get caught in planning or daily scrum. Some sort of conversation like "I'm going to be working on X" "Oh, I was also going to work on X, we should talk" will likely happen.

2) Even if that gets missed somehow, step 1 of TDD (or BDD) is to write a test that fails. When I do this, if someone has already done the work, it should unexpectedly pass.

3) Finally, if we're doing regular code reviews we should, at the latest, see it come up there. At this point we've wasted at most a few hours, which is unfortunate, but not catastrophic.

If this gets to step 2 or 3 frequently, I would hope that a topic in the retro would be why it is happening and how to avoid it moving forward.

  • Thanks Daniel this makes a lot of sense. 1 and 3 will probably be the most likely. We'll be working on our own isolated feature branches so point 2 might not be very often. Maybe this is a good case for us all working on the same dev branch instead. – Lee Jan 23 at 8:05
3

In the case of calls to the audit service, I would spin them off into their own stories:

  1. As a user I want to be prompted to enter my smartcard PIN so that I can login
  2. As an auditor I want to know when a user has attempted to log in
  3. As a user when I enter my smartcard PIN correctly I am taken back to the system so that I can use the system's modules
  4. As an auditor I want to know when a user has successfully logged in

The subject of the story changes from "user" to "auditor".

When a developer works on Story #1, they don't worry about calls to the audit service. Story 3 depends on Story 1.

Story 2 depends on Story 1 as well, so completing Story 1 opens up Stories 2 and 3.

Finally Story 4 is the last to be developed, because it depends on Story 3, and quite possibly Story 2.

                .----->[Story 2]
               /                \
[Story 1]----->                  >---->[Story 4]--->(Done)
               \                /
                .----->[Story 3]

The bottom line is users don't give a crap about auditing, but auditors sure do! The acceptance criteria for end users is different than it is for auditors, so they should be different (but related) stories.

  • Excellent points. We've already had problems with our stories not being broken down enough, so it could be we're still not there yet. – Lee Jan 23 at 8:06
  • 1
    @Lee: You will be surprised at how small stories can be. I struggled with this myself for a couple years. It really depends on the expertise of the team and complexity of the application. A good line to draw in the sand is determining who the feature is focused on. If a story serves two audiences, then it is really two stories. – Greg Burghardt Jan 23 at 12:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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