try {} catch ()

Java, Agile, the Web and other nice things

Jun

9

A few things about Scrum…

By Olivier Gérardin

I recently attended a very interesting 2-day Scrum Master course with Dan Rawthorne, a seasoned agile practitioner, and that made me realize that Scrum is a living thing and has evolved from what I thought I had figured out, and is still evolving… Dan has a lot of experience managing agile projects and is one of the people shaping Scrum day after day. He has a book in preparation which I’m eager to get my hands on.

So, what I was familiar with and had put in practice was what Dan called “Grandpa’s Scrum”, which is actually the original version of Scrum. Nothing wrong with that, but Scrum has been refined since and a few subtle but important changes have made their way into Scrum.

Also, the course made me understand some of the misconceptions I had about Scrum.

So, here are, in no particular order, some points that were mentioned and that I found noteworthy:

  • The sprint backlog is not untouchable! Just because you agreed during sprint planning on what you were going to try to achieve in this sprint, doesn’t mean it can’t change during the sprint… Reality might knock in and force you to change the priorities. What if the server room is on fire? Are you still going to try to stick to the initial plan? Of course not. In any case, the Product Owner is the only one who is allowed to change the priorities, and he can do so at any time, even during a sprint!
  • The “product backlog” is actually called simply the “backlog”, because it does not only contain items about the product, but anything that needs to be done! Similarly, “user stories” are now only “stories”, because they’re not necessarily about the product directly. You might also find them referred to as PBIs (product backlog items). While these terminology changes might seem minor, I think they are necessary because they influence our understanding of Scrum.
  • Stories need to have a “definition of done”, that is a list of conditions that the team agrees will mean the story is, well, done. This might seem obvious or implicit but it is not, because this definition might include some points that are not directly related to the implementation of the story but are crucial nonetheless, such as making sure it’s tested, making sure the code is committed, making sure the code has been reviewed, etc.
  • The Product owner is an integral part of the team! Which means he can’t be on te business side; that would be the Business Owner. The Product Owner is responsible for communicating with the Business Owner, translating his wishes into stories, and prioritizing them. In return the PO is the single person accountable to the BO for how the product is evolving.
  • Estimating stories is (at best) useless, unless you want to fall back in the old waterfall / plan everything ahead model. What matters is: do you want to implement it, or not? Only tasks that derive from stories can be estimated, for the sake of knowing if they will fit in a sprint or not. Stories need only be prioritized.
  • “Backlog grooming”: that’s the action of cleaning up, refining and re-prioritizing the backlog. Of course it’s something everyone does, but it feels good to have a name for it :)
  • Burndown charts are avoidable: since the beginning I found them unnatural; what, a chart going down?? Plus burndown charts actually measure activity, not progress. What do you want to know, how busy the team is, or how fast is the project moving? I assume the latter, then the only thing you’re interested in is how fast stories are solved, period.
  • Subject Matter Experts (SMEs) can also be technical experts (architects, DBAs, …), they’re not necessarily experts in the application domain.

Finally, a note on the Scrum Master role, which this training was mostly bout. This is always the most challenging role to explain to a non-Scrum person, because it has so many aspects, and can’t be appropriately summarized other than saying he’s a “facilitator”… An interesting (and quite sexist, but let’s keep that aside) analogy is that of the family: if you consider the team as a family, then Scrum Master would be the mom: taking care of everyday tasks so that the house is well-run, the children (other team members) are well behaved and play nice with each other, etc. In this analogy the Product Owner would be the dad, maybe away working for part of the day (actually, talking to the Business Owner, stakeholders and SMEs…) but having the last word on what needs to be done and when.

In any case, if you can attend one of Dan’s conferences or training classes, this will be time well spent.

Story: Scrum Master Certification course. Done. Next…

 

One Response so far

Hi, thank you very much for this true words. I am a PO and was having doubts whether i am part of the team or not.

Now i know that i’m the dad :-)

BR
Franz

Leave a comment