November 2006

Monthly Archive

Becoming a Certified Scrum Trainer

Posted by on 26 Nov 2006 | Tagged as: Scrum

The certification process for becoming a Certified Scrum Trainer was a terrificly difficult and motivating experience. As of November 15, 2006, I am now a Certified Scrum Trainer which allows me to work with those people getting introduced, updating their understanding, or advancing their application of Scrum. What a wonderful thought! Although this is about Scrum (it is in the title after all…), there is more to it than that. As some of you may know, the real work in implementing Scrum is not the basic framework (Vision, Product Backlog, Sprint, and Potentially Shippable Product Increment), the three roles (Delivery Team, ScrumMaster, and Product Owner), or the three ceremonies involved (Sprint Planning Meeting, Daily Scrum, and Sprint Review and Retrospective). The real work comes when people start using these.

The process for this certification started about 6 months ago when I started working on the application form which may be found at the CST FAQ on the Scrum Alliance web site. The application form asked for information about why the committee would want to assess my ability to train others on Scrum. The essays were difficult since I had to not only remember the teams and organizations I had worked with in the past with more detail than is usually within my ability but also how that history could make me somebody that can effectively train somebody else on Scrum.

After weeks of working on my essays and finally sending in the CST application form, my CSM-Practicing application, and signed letter of recommendation from a mentor and current CST, I had to wait a week to see whether I would be invited to the first ever assessment event at the Scrum Gathering during the week of November 13-17, 2006. Fortunately, I was invited to be assessed which came with even more ceremony. I would have to develop my own materials for a 45-minute session with an exercise on an aspect of Scrum which would allow the CST certification committee to assess my training skills. I started with a simple story board of post-its on the wall. My wife supported me by listening to some initial deliveries of this material from the post-its. She already understands a little bit about Scrum because we use it for our home improvement work and she is currently the Product Owner. Upon delivering it 4-5 times with my wife, I conducted a dry run of the session with some colleagues at SolutionsIQ in our open space area. The session seemed to go well and I got some great feedback from the group. In a couple of days I was off to Minneapolis, MN for the Scrum Gathering.

Although the help of my wife and fellow colleagues was very helpful, I also had a sargeant at arms for the CST certification event. Their job was to make sure that anything that I made it to my interview and presentation session on time along with assuring that all materials were present in the event room for the presentation session. This was incredibly helpful and allowed me to focus on the presentation session itself. For some reason I was having a hard time sleeping, 1-2 hours, the 3 nights leading up to Wednesday which was the day of the CST certification event. I had one more dry run the night before which gave me some more helpful feedback that I could use on the next day.

Suffice it to say that after going through the interview and then delivering material with current CSTs I was feeling a little bit relieved that it was over. I felt quite satisfied about going through the process and becoming a CST. Along with myself there were 4 other new CSTs:

  • Pete Behrens
  • Pete Deemer
  • Michele Sliger
  • Tamara Sulaiman

I will now get some sleep…zzzzzzzzz

An Exercise to Derive User Stories from the Vision

Posted by on 07 Nov 2006 | Tagged as: Agile, Scrum

If you have ever worked on a project which used Scrum then you may have run into the “blank backlog” issue. Where do we start? Since there are no perfect answers we will need to work this out through experience. I have been using a “Product Backlog filler” exercise with customers which has been refined through these experiences.

When starting a Scrum project it is recommended we begin with a vision. A high level plan of what the product will do from which we can derive a Product Backlog from. I have found that this vision does not have to be written in “stone” (or paper if that is what you use…) but it should be in a form that can be communicated effectively (pictorially on a white board potentially…). A vision is usually followed quite closely by a list of value statements for the consumer of the product. If we can identify the value for our consumers then we have a nice foundation to start driving out user stories from.

In most situations I have found it best to have the Product Owner and ScrumMaster (possibly myself) work on the initial Product Backlog. This allows for a coherent product development story to be constructed before working with the delivery team. This is not a hard and fast rule since I have recently broken this trend because of the project type and delivery team experience with Scrum. When we have a list of product consumer value phrases created I will place these on a white board or visualization instrument (easel pad, index cards taped on a wall, etc…). We then ask the question “Who wants and supports these value statements?”. This creates a discussion of potential roles and parties to the product being developed along with defining their characteristics. While listing out these roles and parties we may generate some that are not valid or can be merged into a more suitable description. This is great since the discussion will then better define the role and party boundaries.

After this discussion of the roles and parties either attaining or supporting the value statements, we can start to work on the “goals” which will give them the list of values stated. This will usually start with a value to be achieved and a role or party that is interested in this value from the product. Once we decide on these then it is just a matter of writing as many “goals” as possible to make this happen in the product. I use the term “goal” as it is identified in the User Story template by Mike Cohn:

As a <user>, I want to <goal> in order to <value>

Where is one of our value statements identified from the vision, is the role or party identified to attain or support the value statement, and is the list of features which will achieve the value statements for our identified roles and parties. Now that we have all three parts of the User Story template we can write out the actual user stories and put them into our Product Backlog to start a “good” conversation with the delivery team.

In this blog entry I have identified one method for driving out user stories for a Product Backlog which I have found to be useful. There are many other methods which achieve the same goal. I suggest that anybody using Scrum should take a look at how user stories can be used as a powerful way to capture features to be developed in their products. The template developed by Mike Cohn for user stories has been quite powerful in projects I have been involved with and is further explained in his books “User Stories Applied” and “Agile Estimating and Planning”. Take a look at these for more information and other supporting methods for developing products through the user story medium.