Scrum Shortcuts the Video Series from Ilan Goldstein

Aussie Scrum expert Ilan Goldstein has made the perfect accompaniment to his handy book of scrum tips called Scrum Shortcuts without Cutting Corners.  It’s very handy reference to anyone wanting to get through those tough episodes we all experience in product development with its slant clearly on Scrum – I find the tips to have a universal appeal as well.  Here’s a bit of a summary and teaser for you to try the video series yourself.

On FrontRowAgile Ilan talks us through his tips and experiences by diving them up into five broad categories.

  • Planning and Protecting
  • Requirement Refinement
  • Establishing Estimates
  • Monitoring and Metrics
  • Reviews and Retrospectives

Planning and Protecting

Here we get tips on Sprint Planning.  Scrum tells us to do this to set up a goal for a team to deliver value to their customers.  There is important psychology that backs this up.  To quote Tim Lister and Tom DeMarco – ‘Providing lots of satisfying closure, one of the key elements of a chemistry-building strategy for organisations’  Maintaining a rhythm via sprints and the ceremonies within helps teams achieve results.

Visual representations help a lot.  The brain processes visual information 60000 times faster – from what I hear 🙂  So it follows that it would aid human psychology.  It’s more stimulating and we gain information just from passive observation.  So the task board is a central part of Scrum – actually the Scrum Guide tells us to use any visualization that makes sense and the task board almost always does.

In addition to this other visual artifacts help us like the sprint burndown and a prominent display of the Sprint Goal.  It becomes part of the team’s rituals.  Place them near the board.

A sprint is never without hurdles.  Visualize these (risks) as well.  A memory peg helps to CONTROL your issues.  The acronym helps as follows:

Confirm, Triage, Remove, Outline and Learn.  – Ilan explains more in the video 😉

Requirement Refinement

It’s important to divide stories into tasks.  A mistake is divide stories on a technical basis.  It’s common to see UI, Business Logic, Data Logic splits across an entire story.  Find a split that delivers a slice of functionality that cuts through the layers of technology and deliver that.  For example username/password of a Login story.

Sometimes we do need to deal with a technical requirement.  Try and fold those into something that is useful to the customer.  The use of user story format for technical stories is a bit of square peg in round hole.  Don’t sweat that if it happens.

A word on completing those stories and tasks with the well known definition of done.  That checklist that a team uses to ensure that when they say they are done they are done.  The team creates and owns this, but we do expect to see similar items across many software teams. Examples like unit tested and peer reviewed.  The DoD operates at task, story and release level – have one for each level.

Establishing Estimates

We learn about using story point estimation.  It’s useful to factor three planes into the estimation, namely Complexity, Repetition and Risk.  We don’t need detailed specs, rather other items to compare against – that is benchmarks from historical performance (or fake it til you make it – i.e. till you create history, use your best guess).  We learn about the approach to Planning Poker – a big take away is to incorporate diversity and it’s a common pitfall to assume experience is all that counts.  Some tips are provided on planning poker – rather than repeat them all (you should watch the video for that) some are re-estimate classes of stories when discovery of a wrong estimate occurs and to facilitate respectful debate on differing sized stories as opposed to a deconstruction.

Monitoring and Metrics

Metrics need to matter – rather than metrics matter.  They are a guide to inspect and adapt and not a tool or wedge against individuals.

Many teams find the sprint burndown chart to be useful as a guide on progress.  Used honestly it will highlight issues visually that a team can use to correct itself during a sprint (i.e. we aren’t going so well) or for when more work can be pulled in (we are doing well).  The same can be applied at the release level as well.

The daily scrum is an important monitoring ceremony. An effective standup is pivotal to being able to move tasks do a done state through the three questions (What I’ve been doing, What I intend to do and What is blocking me).  Keep it short and on topic and agree to fix issues outside the event.  To keep it interesting try by energising the event like throwing around a toy and change that up when it starts to wane.

Early and continual walkthroughs during the sprint are important for feedback from the PO and from others.  It will make the Sprint Review more of a tick and create a more valuable experience when that event occurs because it can focus on outcomes and looking ahead.  A walkthrough is a checkpoint that keeps us within the sprint goal and on track.

Reviews and Retrospectives

The Sprint Review is a momentus event and should be handled as such.  Be prepared with Demo Data and a real staging environment and not smoke and mirrors – the PO could say to roll forward to production with the increment.  Let the attendees know beforehand with an agenda and ensure the location is booked and setup with all that is necessary like a whiteboard and the hardware.

When running it consider it more like a collaborative workshop rather than a demo.  A two way exchange is therefore encouraged. Keep the meeting on topic with off-topic conversations acknowledged and agreed to be parked for later.  The development team gets a feel for what’s coming next and is able to ask questions around that.

Those receiving the product increment get a feel for how the team went about the delivery fostering an empathic view of the effort.  An enjoyable review is an indicator of success.

With the retrospective, the team has it’s all important opportunity to reflect and celebrate it’s wins and also to think deeply about where it can improve (invite the PO as well).  Ironically when the pressure is, is when it’s most useful.  Scrums values really do come into play in this event:

Scrums Values

Scrum Values

Some popular topics for focus are around communications, process, scope, quality, skills, environments with an aim to have actions that can be delivered in an upcoming sprint (don’t do them all if there are many – rank them).  Keep those actions visible near your task board.  A couple of interesting retrospective techniques are represented (circles and bubbles) with these suiting newer teams – with mature teams, just shooting the breeze works well.


Doing Scrum is more than going through the motions.  Ilan conveys throughout the videos this ethos.  Look deeper, be prepared for the hard stuff and learn from the experiences and everyone will be winners.  This video series will help with great tips to aid in your scrum and agile journey.


One response to “Scrum Shortcuts the Video Series from Ilan Goldstein

  • Nick

    Estimating via Planning Poker is good, probabilistic forecasting is an even better improvement and more predictable. That’s next level scrum – no one said planning poker was part of scrum anyway.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: