The Scrum Methodology is the title of an IT Conversations podcast with one of the more bait-and-switch titles I’ve seen in awhile as only the first 25 minutes or so, and the rest of the hour is Twitter and marketing and such. But the first bit, the one that is actually aligned with the title isn’t a regrettable loss of time.

And since we’re on the subject of scrum, here is a link to the Scrum Guide from the Scrum Alliance.

Now, onto the notes.

  • Product Owner…
    • … has the ability to make all product decisions with engineering. And trade-offs
    • … if more than just a product manager
  • They have a a war room…
    • … which has magnetic whiteboard on all sides
    • … 300 – 400 cards on the walls of the war room
    • … one wall is all the user stories
    • … once the stories are estimated, then they move to the engineering wall
  • Everyone needs to buy into the process to create a well oiled machine
  • User stories are…
    • … created when you hear requirements or think of features
    • … in user visible terms – user would understand them if they heard them
    • … from the perspective of user interacting with your platform
    • … or how the user is supposed to use it
  • Big stories are ‘epics’
  • Stories have to be small enough that a developer can estimate it
  • Developers can look at a story and say ‘these are the n tasks that come out of it’
  • Spikes – research to come user stories and estimates for them from the epic
  • 2 types of planning meeting:
    • Release – take user stories and estimate stories. Don’t know which release they will go in
    • Sprint – these are the user stories that should go into the release
  • Estimating a user story
    • Estimate the work, not the time
    • 1: not much work
    • 3/5: whole sprint, at risk
    • 8: have to break it down
  • Accountable on a daily basis in the meeting is what makes the whole thing work
  • What’s the disaster recovery plan for the recipe cards getting lost / rearranged?
  • Pair programming – everyone knows what everyone else is working on, owns all the code
  • At the end of a sprint, should be able to take a drop and release it to a customer
  • Their two week sprints go Wednesday – Wednesday
  • On the final Wednesday, close out the items from the sprint and have a demo of sprints features and hold retrospective on what worked / what didn’t
  • Scrummaster – ensures meetings run on time, process is working or modifies the process
  • Scrum doesn’t dictate sprint length, but recommend less than a month as that is limit(ish) that engineering can see into the future
  • The trick with enterprise clients is to align them with sprints rather than external and around the sprints
  • Works best with a team size of 8 – 12
  • acunote – hosted scrum management tool