Control Chaos with Scrum 9

Posted by Conrad Benham on August 17, 2008

On Tuesday, Aaron Farr of JadeTower gave a very entertaining and informative overview of Scrum. Drawing on experience gained from working in Scrum teams at Siemens, Aaron was able to provide a thorough insight into the process.

Aaron opened by discussing how Scrum is a lightweight process that manages the chaos associated with building software. This chaos is controlled by providing guidelines designed to limit the impact. Various roles are necessary to enable this including a Product Owner, Scrum Master and Scrum Team.

Scrum is an iterative style of development where certain pieces of functionality are delivered in a fixed period of time known as Sprints. Aaron introduced the notion of a Product Backlog which is held in user stories and can be estimated and prioritised. The product backlog is defined during the planning meeting that occurs prior to the commencement of a sprint. The sprint runway was also discussed which clearly defines work that is to be complete.

Some interesting questions were raised as to how stories should be estimated. The two concepts are intuitive hours and the somewhat abstract idea of story points. Either way story estimates help determine velocity which can be used to create burndown charts.

Aaron ended the evening with a highly interactive session in which he demonstrated the creation of stories that were subsequently estimated. In this entertaining session he asked for input from people to determine the relative size of each story. That is, the size of each story in comparison to other stories that were estimated. The first story chosen was used as a baseline to estimate the size of subsequent stories.

Aaron has kindly put his slides on Slideshare. He also suggested people refer to the Scrum Checklists on InfoQ for more information in the way of mini-books about Scrum. Aaron also made reference during his presentation to the page You Aren’t Gonna Need It hosted on C2.

Trackbacks

Use this link to trackback from your own site.

Comments

Leave a response

  1. Robert Lowe Tue, 19 Aug 2008 01:42:03 UTC

    It was great to hear about Aaron’s experience with Scrum.

    Some photos from the talk are at the link below:

    http://www.flickr.com/photos/rmlowe/sets/72157606785371517/

  2. Steven Mak Thu, 21 Aug 2008 01:25:13 UTC

    It’s an interesting talk.

    There are a few things I could recall from the presentation that I think should be added.

    1) Use Case vs User Stories

    They are indeed different from at least two perspectives:

    * Scope and completeness, user story usually covers the main success scenario, while a use case covers the main success scenario plus acceptance tests.

    * Purpose and longevity, story cards are usually discarded after an iteration, while use case is good as a permanent artifacts for documentation.

    References:

    http://www.mountaingoatsoftware.com/article/27-advantages-of-user-stories-for-requirements

    http://www.agilemodeling.com/practices.htm#ApplyTheRightArtifacts

    http://www.infoq.com/cn/news/2008/08/use-case-or-user-story

  3. Steven Mak Thu, 21 Aug 2008 01:35:07 UTC

    2) A team choosing less work than they are capable of?

    I would like to point out that Burndown chart is not the right artifact for this problem.

    The planned velocity was reflecting the story points the team chose to finish. In that case, that was a story point with relatively small value (compare to what the team should be capable of).

    If that is less than what the team is capable of, then it is very likely that the actual velocity won’t leave too far away from the planned velocity.

    The result is having a very nice Burndown Chart but the customer gets little value by the end of the iteration.

    I think the better answer for this question is:

    1) Daily Standup meeting. PO are welcome to attend. It is also a good way to establish trust and see that the team is fully committed to the work, whether they have difficulties or not.

    2) Asking questions, it is true that Scrum Master is not the person to manage nor dictate what the team should do. Scrum Master can ask questions to the team on their decisions. This is not a challenge nor showing authority, but to understand rationale behind the decisions made by the team. This could also reveal if impediments exist, and it is Scrum Master’s responsibility to remove impediments to the team. So identifying potential impediments is also important for Scrum Masters, and that’s why a sensible Scrum Master should ask questions to the team when he/she smells something not quite right.

  4. Steven Mak Thu, 21 Aug 2008 01:36:42 UTC

    oops, seemed the part 1 of the comment disappeared…. or is it filtered somehow?

  5. Conrad Benham Fri, 22 Aug 2008 08:41:59 UTC

    It’s retrieved now. Strangely, the spam filter caught it.

  6. Naman Joshi Thu, 28 Aug 2008 11:08:11 UTC

    This is a very interesting site. When is your next meeting?

  7. Conrad Benham Fri, 29 Aug 2008 00:42:39 UTC

    Good question Naman. You can expect the next round of events (code jam and talk) in the next couple of weeks. I will announce them when I have confirmed the plan.

  8. cloneofsnake Fri, 29 Aug 2008 16:39:47 UTC

    Interesting… I’ve been reading up on Feature Driven Development recently and there are definitely some similarities between that and Scrum.

    Love the slides, wish I could’ve been there. Any other good sources online? Thanks!

  9. Recent Links Tagged With "scrum" - JabberTags Mon, 13 Oct 2008 19:34:28 UTC

    […] public links >> scrum Control Chaos with Scrum Saved by happyexpat on Sat 11-10-2008 Transition to New Server… Saved by lrf77 on Thu […]

Comments