That’s what you get when you combine ScrumMaster certification with Easter.
I am now a Certified ScrumMaster. This achievement involved attending the two day course, absorbing a massive amount of well delivered theory, actively demonstrating Scrum method within teams, and passing a multiple choice exam when I got home (although I did have 60 days to do the last part).
I was surprised I passed the first time as the questions are designed to trip you up (much like the driving theory test), but I assumed my knowledge would only atrophy and that it was best to strike while the iron was hot.
Hurrah!
What was new?
The most interesting thing I learned about Scrum was all the things that aren’t actually Scrum. There are many Agile methodologies that have fallen into a melting pot of Agile tools. In particular, Extreme Programming gave us User Stories. In Scrum, we would refer to a User Story as a Product Backlog Item.
What’s a User Story?
User Stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a <type of user>, I want <some goal> so that <some reason>.
Essentially they are just bits of work that need to be done within a Sprint, broken down into its simplest and most transparent form. This is necessary in order to estimate the time involved to complete this piece of work.
If a User Story is a particularly large piece of work, it rather compellingly called an ‘epic’.
Although User Stories are not traditionally a part of Scrum, they are widely adopted. After all, ‘traditionally’ has no place in an Agile process.
Here are some Scrum FAQs for those craving more on the differences.
What went down?
My personal acronym library has expanded. My favourite is PSPI: Potentially Shippable Product Increment. Which basically means you have a piece of work that is potentially ready to be shared with the client. And that should happen at the end of a Sprint.
We had a brief to build a house for a Lego family, and as a team we broke down the work into User Stories, estimating the time/effort involved. This included a secure home with 2 bedrooms, a garden, a power supply, food, water and sanitation. This was all without having a good idea of what Lego we’d been provided with, to bring home the point expect the unexpected – plans change!
It worked well – we had doors and windows, a roof, a septic tank, a mailbox and a sky dish. This was the moment that every professional in the room became 5 years old again.
Happily, we completed our Lego house before the 10 minute deadline and I was able to add a white picket fence around the property which was immensely satisfying. In fact, the hardest part of the day was putting the Lego down.
We swapped our work with another team (playing Stakeholder). We agreed we’d hit our targets. Though I felt they were unreasonably critical of my mailbox.
Lessons learned
Which brings me to the part I enjoy most – the retrospective.
- What went well during the sprint cycle?
- What went wrong during the sprint cycle?
- What could we do differently to improve?
Everyone writes down something they think could have been done better. Then we make sure there are no duplicate suggestions.
From that, we look at how many things ‘to fix’ there are. You don’t want too many things to take on board for your next Sprint. So the team votes on the three most important suggestions for productivity, team formation and bonding.
The retrospective helps build the team’s sense of ownership and its self-management. The importance of this feedback loop in our commitment to evolve and improve cannot be overstated.
What’s next?
I’m back on the job, facilitating the morning Scrum, helping to outline what we offer as a company, and ensuring the team is self-organising pleasantly.
This Thursday I will run my first Sprint Retrospective. Tips are welcome.