This story describes how we came to create our course Scrum with Agile Requirements: Achieving Sustainable Agile which is an integration of Scrum and Acceptance Test-Driven Development.
We had a client that had about six teams that wanted Scrum training along with their product owners and Scrum Masters. All told there were about 50 people, some being remote. Our normal Scrum training took two days and had a maximum class size of 25. The limit is because at larger class sizes the people get less interactive and this results in less effective training. Budget limits meant that we couldn’t do the normal follow up coaching we like to do because without it, the training often just bounces off.
We had three problems. The first was that two-day course would not be very effective since we could not do follow up coaching. The second was there was no way the “as a <user> …” story writing method would work because they had a very complex problem domain. The third was that the budget required us to offer only one delivery with a class size twice what we normally preferred.
At this point, we recalled a client from many years ago that wrote virtual operating systems where the “as a <user> …” construct could be used only for one or two levels and not get stories smaller than several weeks of work. In that case, we had taught them the Given-When-Then construct of Behavior-Driven Development (BDD): “Given <situation> When <event occurs> Then <we get this behavior>.”
We came to the conclusion that we had to offer Scrum integrated with BDD. But how? We had taught Scrum in the past with the Dot Game and we had done it with 200 people once at an Agile Alliance Conference, so we knew 50 folks wouldn’t be a problem. We slightly modified our normal Scrum course to be 80% games and exercises and figured the BDD course we had done could have 50 people in it in the mornings and the afternoons were coaching teams anyway.
Thus, Scrum with Agile Requirements: Achieving Sustainable Agility was born. And it worked brilliantly. We won’t teach it any other way now.
My favorite statement from a participant illustrated how well it worked. On about Day 3, a Product Owner said, “Oh, I see. Instead of figuring out how much I can get in a release, I should be figuring out what slice of value I can deliver soonest.” Bingo!