Professional Scrum Developer Course – New Delhi Day 1

scrumdevlogoI’m in India at the moment with Damian Brady and Adam Stephensen running a Professional Scrum Developer course. The training is with a group of 24 guys with varying roles – developers, testers, architects, and managers. At the end of the course, they will all have the opportunity to sit an online exam to become “Professional Scrum Developers”.

It was such a fun day, we decided to sit down and write a blog post together.

Pre-day one

We decided to catch a couple of tuk-tuks to the venue.  I still managed to send emails on my iPad while cramped in the back.


Figure: Setting off on our way…. little did we know that the driver had no idea where he was going

One of the important things you learn about in Scrum is an Impediment.  Even before day 1 started, we had our first one.

Impediment 1: The distance from our hotel to the training venue was about 2km.  The 1.5 hour journey (yes, one and a half hours) to this venue on the first day included three lost taxis (two independently finding their way to the same wrong address) and several near-death experiences.

Tip: Don’t think about complaining to your tuk-tuk driver or else you will find him try to make you happy by driving the wrong way down a busy main road.


Figure: Our tuk-tuk driver saving time – you have no idea how we felt.

Getting Started with “Scrumdementals”

Impediment 2: Day 1 officially started with me noticing that only one of the 24 students had read the Scrum guide. To bring everyone up to speed, I gave a succinct rundown of the Scrum user guide with the help of a few SSW rules (The importance of a team, Reading the Scrum Guide, and Physical Task Boards) and the awesome “Scrum Master in Under 10 Minutes” video by Hameed Shojaee.

The “guts” of Scrum was covered, with particular reference to short iterations, multi-skilled teams and timeboxing.  I also told a story about my years in the army, and pressed  the point about the “inspect and adapt” tenet of Scrum which got a laugh.  The army tends to plan a mission, watch it all go very differently, and then debrief so they can adapt.

Adam Cogan getting some laughs from one of the teams

Figure: Me telling the team what they “said”, but what the Product Owner really “heard”

I talked about the burndown and asked which time fields in a User Story mattered for the burndown.  Two of the 24 students already knew that the only time field that Scrum cares about is the “remaining time”.  I explained why this was, and why the “original estimate” and “actual time” spent fields aren’t as important.

User Stories

After a morning break, I spoke to the group about User Stories.  I did my quintessential example with accompanying story:

As a marketing manager
I want to search for customers
So that I can call them up

I followed this up with a discussion about Acceptance Criteria and why they were so important.  Referencing the SSW rule on Acceptance Criteria, I was pointed out that you should never assume “gold plating” for a User Story.  The group appreciated the clarification on acceptance criteria and agreed that it was important for clarity.

My next instruction was for each student to write one of their current working items in the form of a SSW story card.  Some were good, and some were not so good.  Damian reviewed his favourite ones to the class.


Figure: Rohit Arora’s great Story Card


Figure: Manish Yadav’s great Story Card


Figure: Sanjay Saini’s great Story Card


Figure: Amit Choudhary’s great story card

Sprint One

After lunch, the group was asked to self-organise into four teams of six.  Initially, the groupings weren’t ideal (all the developers with MVC experience were in the same team), maybe the ‘multi-skilled’ point was forgotten… a quick bit of shuffling was required.

The teams really worked well together

Figure: The teams really worked well together

Bonus 1: Even though team members were being split up, the new teams worked really well together.

Next, the Product Owner entered the room and scared everyone with his tough requirements. He is a Product Owner you don’t want to mess with.

The Product Owner giving his requirements

Figure: The Product Owner giving his requirements

The Product Owner spent 10 minutes (timeboxed) giving out requirements for the first one hour sprint. The task was to create a poster for his boardroom.  The sprint was split into four 15min “days”, after which the teams presented the results in the review meeting.

Impediment 3: Every half hour or so, a “black room event” occurred. No, not a “black swan event” :-).  Apparently power outages are fairly common in Delhi, but every time it happened, the laptops switched to battery and all network connections were lost.

I saw this message pop up on my PC quite a lot:


Figure: The all-too-common Battery Monitor message

The post-sprint Review meetings were fun with the teams presenting some different results in their work.  The Product Owner was hard to please, but I think under that tough skin, he was generally pleased with the work.  The same can’t be said about the process.  In the end, he chose his favorite diagram to hang on his boardroom wall.

The Product Owner giving his requirements

Figure: The Product Owner’s favourite diagram had some excellent artwork

The Retrospective meeting was even more fun and the teams learnt some very valuable lessons.  However, I explained that every one of the teams was naughty:

  1. Only 1 of 4 teams took up the invitation to speak to the Product Owner about what he wanted
  2. 2 teams did a User Story for the task (despite Adam C giving several “Printed Story Cards” to each team)
  3. None of the teams kept a Backlog
  4. None of the teams did a Daily Standup, and
  5. Only 2 teams followed the brief and included pretty pictures (this was very important to the Product Owner)

Later on, I presented my ideal Scrum diagram and spoke about how it clearly shows the Scrum process from start to finish.

The Product Owner's Ideal Scrum Diagram

Figure: My ideal Scrum diagram


The day ended with a retrospective where each student talked about what they liked and disliked about the day.

The top two highlights of the day – repeated multiple times – were:

  1. Writing User Stories and learning about why the wording was important
  2. Learning about effective acceptance criteria

The students said they were very happy with the course so far. They wanted 2 things improved for the next day:

  1. There weren’t enough videos (we’ll fix that on day 2!)
  2. Lunch was too early

Can’t wait for Day 2.