0 Comments

The Agile Project Management course that I tutor at QUT (now known as IAB304) is primarily focused around the DSDM Agile Project Framework. That doesn’t mean that its the only thing the course talks about though, which would be pretty one sided and a poor learning experience. It also covers the Agile Manifesto and its history (the primary reason any of this Agile stuff even exists), as well as some other approaches, like Scrum, Kanban and the Cynefin Framework.

Scrum is actually a really good place to start the course, as a result of its relative simplicity (the entire Scrum Guide being a mere 16 pages), before delving into the somewhat heavier handed (and much more structured/prescriptive) DSDM Agile Project Framework.

Of course, Scrum fits in a somewhat different place than the Agile Project Framework. Scrum is less about projects and more about helping to prioritise and execute a constantly shifting body of work. This is more appropriate for product development rather than the planning, execution and measurement of a particular project (which will have its own goals and guidelines). That is not to say that you can’t use Scrum for project management, its just that it’s not written with that sort of thing in mind.

Often when tutoring (or teaching in general) it is far more effective to do rather than to tell. People are much more likely to remember something (and hopefully take some lessons from it), if they are directly participating rather than simply listening to someone spout all of the information. A simulation or game demonstrating some lesson is ideal.

Back in September 2014 I made a post about one such simulation, called Scrumdoku. In that post, I also mentioned a few other games/simulations that I’ve run before, one of which was Scrum City.

It is Scrum City that I will be talking about here, mostly because its the simulation that I just finished running over the first two tutorials of the semester,

A City of Scrums?

The premise is relatively simple.

The mayor of some fictitious city wants a scale model of their beloved home, so that they can display it to people and businesses looking to move there.

Those of you familiar with the concept of a Story will notice a familiar structure in that sentence.

As a (mayor), I want (a scale model of my city), so that (I can use it to lure people and businesses there).

Like all good stories, it comes with some acceptance criteria:

  • All items in the model must be made out of lego.
  • Roads, lakes and other geographical features may be drawn.
  • The model must fit on a single piece of A3 paper.

Now that I’ve set the stage, I’ll outline the process that I went through to run the game over the first two tutorials.

Breaking Up Is Hard

I have approximately 55 students in my tutorial. For most of the work during the semester, I break them into groups of 5 or less (well, to be more accurate I let them self-select into those groups based on whatever criteria they want to use).

For Scrum City, 11 groups is too many. For one thing, I don’t have that much lego, but the other reason is that acting as the product owner for 11 different groups is far too hard and I don’t have that much energy.

The easy solution would be to try and run one single Scrum City with all 11 teams, but the more enjoyable solution is to pit one half of them against the other. Already having formed teams of 5 or less, I simply allocated 4 of the larger teams to one side and the remaining teams to the other.

Each side gets the same amount of materials, and they both have approximately the same number of people, so they are on even ground.

The Best Laid Plans

The very first thing to do is to get each group to elect/self-select a Scrum Master. For anyone familiar with Scrum, this is a purely facilitative role that ensures the Scrum ceremonies take place as expected and that everyone is participating appropriately. It helps to have a Scrum Master, even for this short activity, because they can deal with all the administrative stuff, like…

The creation of the backlog.

Creating the backlog is a good opportunity to explain how to create a good story, and the concept of acceptance criteria. Each group needs to figure out a way to farm out the production of around 40 stories, each describing a feature that you (as the mayor) wants to be included in the model. Participants should be encouraged to ask questions like what it means for a one story house to be done (i.e. how big, to scale, colour, position, etc) and then note down that information on an appropriate number of index cards (or similar).

Each backlog should consist of things like:

  • 5+ one storey houses (as separate cards)
  • 5+ two storey houses (again, separate cards)
  • 5+ roads (of varying types, straight, intersections, roundabout, etc)
  • hospital
  • stadium
  • statue
  • bridge
  • police station
  • fire station
  • …and so on

It doesn’t actually matter what elements of a city the stories describe, it’s whatever you would prefer to see represented in your city.

Spend no more than 30 minutes on this.

As Big As Two Houses

Once the backlog is complete, its time for the part of planning that I personally hate the most. Estimation.

That’s not to say that I don’t understand the desire for estimates and how they fit into business processes. I do, I just think that they are often misinterpreted and I get tired of being held to estimates that I made in good faith, with a minimum of information, in the face of changing or misunderstood requirements. It gets old pretty quickly. I must prefer a model where the focus is on delivery of features as quickly as possible without requiring some sort of overarching timeframe set by made up numbers.

Each group will be responsible for ensuring that every story they have is estimated in story points. A lot of people have trouble with story points (especially if they are used to estimating in hours or days or some other measure of real time), but I found that the students were fairly receptive to the idea. It helps to give them a baseline (a one storey house is 2 points) and then use that baseline to help them establish other, relative measures (a two storey house is probably 4 points).

There are a number of different ways to do estimation on a large number of stories, but I usually start off with Planning Poker and then when everyone gets tired of that (which is usually with a few stories), move over to Affinity Estimation.

Planning Poker is relatively simple. For each story, someone will read out the content (including acceptance criteria). Everyone will then have a few moments to gather their thoughts (in silence!) and then everyone will show their estimate (fingers are a good way to this with a lot of people). If you’re lucky, everyone will be basically in the same ballpark (+- 1 point doesn’t really matter), but you want to keep an eye out for dissenters (i.e. everyone things 4 but someone says 10). Get the dissenters to explain their reasoning, answer any additional questions that arise (likely to clarify acceptance criteria) and then do another round.

Do this 2-3 times and the estimates should converge as everyone gets a common understanding of the forces in play.

Planning Poker can be exhausting, especially during the calibration phase, where there is a lot of dissent. Over time it usually becomes easier, but we’re talking weeks for a normal team.

Once 3-4 stories have been estimated using Planning Poker, its time to switch to Affinity Estimating.

Spread out all of the unestimated stories on a table or desk, place stories that have been estimated on a wall in relative positions (i.e. the 2 pointers at one end, 10 pointers at the other with room in between) and then get everyone in the group to silently (this is important) move stories to the places where they thing they belong, relative to stories with known estimates. Everyone story should have an estimate within about 5 minutes.

Keep an eye on stories that constantly flip backwards and forwards between low and high estimates, because it usually means those stories need to be talked about in more detail (probably using Planning Poker).

Affinity Estimating is an incredibly efficient way to get through a large number of stories and give them good enough estimates, without having to deal with the overhead of Planning Poker.

Again, spend no more than 30 minutes on this.

What’s Important To Me

The final preparation step is prioritization.

Luckily, this is relatively simple (and gets somewhat repeated during the planning sessions for each Scrum City iteration).

As the mayor (i.e. the product owner), you need to provide guidance to each team as to the relative importance of their stories, and help them to arrange their backlog as appropriate.

Generally I go with basic elements first (houses, roads, etc), followed by utilities (hospital, school, police station, etc) followed by wow factor (statue, stadium, parks, lake, etc). Its really up to you as product owner to communicate the order of importance.

You can (even though it is not Scrum) introduce the concept of MoSCoW here (Must Have, Should Have, Could Have, Won’t Have) and label each story appropriately.

The most important thing to have at the end is some measure of the priority of each story, so that when the teams start planning for their iterations, they can create a basic delivery plan taking your preferences into account.

Because the prioritization is less of a group activity than the others, you only really need to spend around 10-15 minutes on this.

To Be Continued

This post is getting a little long, and I’m only about half way through, so I’ll continue it next week, in Everyone Loves Lego: Part 2.

There will even be pictures!