Where do you put scenarios on a scrum board?

Question

So traditional scrum board looks something like this

Backlog       |       Story    notStarted   inprogress    Done
story 1               Story1   tasks       
Story 2               Story2   tasks
Story ..
Story n
Epic  x
Epic  x+1

However in general a story has many scenarios and when working with BDD you want to write each scenario for a story as Given, when and then. Also the scenarios don't belong in the notstarted column, inprogess or Done as a scenario is not a task.

So you realize that a scenario/s should have their own column between "story" and "notstarted", as a scenario can have many task to be considered done.

If you are going to build your task from scenarios then why would you need the story on the scrum board in the first place, maybe they should be left in the backlog.

Some people put scenarios on the back of each story.

This is a on going debate in my team and I wanted to see if anyone has solved this differently.

Cheers!

Answer 1

I agree with Lunivore when she says the conversation is the single most important thing. But this isn't a conversation about BDD nor is about who should write the scenarios.

I think this question is more about if you don't store the Acceptance Criteria digitally how do you capture the Scenarios visually?

• Having Acceptance Criteria then sticking on a whole bunch of scenarios on them means you'll need one very large scrum board and you'll run out of space quickly.

• Having a conversation in theory sounds great but how do you remember said conversation when trying to prove they work afterwards? We are assuming that you will not forget these, and it could be alot of info to keep rattling around up there.

I think you need to concede that there is a need for them to appear digitally. Heck the developers will be typing them out in code anyway. I think the key to them being valuable is getting re-use from them and avoid duplicating effort.

At the very least if they are typed out in Given When Then, then the developers can copy and paste this as a starting point to generate some tests.

I am currently seeking a lightweight solution myself for the same thing. Should I use wiki? speadsheet? Trello? Selenium IDE? Buy a heavyweight tracking tool like Version One, Jira? Cucumber? Twist? Should I not write them out freehand by pen and paper and just print them out? All possibilities.. I don't know the answer yet, but I do know I need somewhere for these scenarios to live, breathe, and evolve.

User stories and scenarios have iterations of there own and everyone should be empowered to edit them.

Answer 2

It sounds like your definition of "scenario" is "BDD test". If that's the case, the scenarios should be part of the acceptance criteria. They don't need their own column any more than individual functions in your code need their own column. Since writing the actual test is a task to be accomplished, you can represent the scenarios as tasks that need to be completed.

My team writes acceptance criteria on separate cards that we tape behind the story card, so you can flip the card up and see the acceptance criteria. You could also do that with your scenarios.

Your other option would be to redefine what you call a story. Call your stories "epics", and call your scenarios "stories". Then, you have one story card for each scenario that you are trying to implement.

Bottom line, though, is do what works for your team. There is no scrum police that will come knocking if you deviate from the standard. If you're really concerned, consider hiring a trained scrum master to come in and do some training or consulting.

Answer 3

My suggestion is to do what is valuable for your team. There is nothing sacrosanct about the traditional scrum board. If you feel that putting scenarios instead of stories gives you better information, then go ahead and do that. Create a board like this if you want

Scenario  |   Not Started    | In Progress  |  Done

The advantage of having stories in the board is that its easy to see when a particular story is done. It helps avoid the case where you finish many scenarios, but none of the stories are complete. If you want to visualise that, then you can do a board like this

Story  |   Scenario  |   Not Started    | In Progress  |  Done
story1       scen1        task1
                          task2 ----> tasks flow this way
             scen2        task
story2       scen1        task

Another thing you might want to do is to convert the tasks into columns. So lets say that your usual tasks are like Coding, Testing etc, then how about a board like this

Story  |   Scenario Not Started |   Scenario In Dev    | Scenario Test  |  Done
story1           scen1
                 scen2 ----> scenarios flow this way
story2           scen1

Another option is to remove the story from the board, and use the card colour to identify the story

Scenario Not Started |   Scenario In Dev    | Scenario Test  |  Done
   scen1 (red card)
   scen2 (red card) ----> scenarios flow this way
   scen1 (blue card)

As you can see, you are only limited by your imagination. Dont be stuck with the "traditional scrum board". Think about what you want to do and create a board that suits you.

Answer 4

Scenarios are intended to let you have conversations. With scenarios, you stand a good chance of finding areas of requirements that you weren't even thinking about.

Writing things down makes your brain write them down too, and then you stop questioning. If you're writing down a scenario, it should be because:

1. It wasn't obvious, and you want people who come after you to understand it too
2. You want to be sure that you really understand the behavior of the system, and talk through an example with someone knowledgeable.

Stop worrying about the columns on the board, and think about how you actually interact with your business stakeholders and analysts.

If there's no gap in conversations, you're part of the same phase, and you don't need to differentiate this on the board.

If there's a gap, does it happen before or after you want to start work? There's no reason why business people can't talk to you before hand about the scenarios they want to play. They're not a phase of work being done; they're just an illustration of the behavior you're looking for (before you code) and a test that the behavior is there (after you code). Scenarios are a great way to question your understanding, and your business expert's translation, of requirements.

If you find for any reason that conversations with your business analyst and tester happen in a different phase to actually coding the work, try and make it closer. Ask them what it should look like and knock the GUI up, then get their feedback. Take on board what they're saying and make that the next thing you do. It'll take longer from your perspective, but the quick feedback means that whatever you produce will be ready for production in a usable form, without the knowledge of how you produced it or how you will fix any bugs degrading over time.

In short, don't worry about writing the scenarios down until you've worked out which ones are valuable by talking to people. Good luck.