What is Scrum?

Scrum is a framework or rules that allows you to tailor your own lightweight process to develop new products. Scrum is simple, it can be understood and implemented in a few days, but it takes a lifetime to master.

“Scrum is not a methodology – its a pathway” Ken Schwaber

Scrum will also help you fail in less than 30 days.  Unlike the waterfall method where the product is fully developed and then sent for testing.  Scrum works in iterations of 30 days (or less if you have chosen short sprints).  Each Scrum Iteration will aim to have potentially shippable code at the end of the iteration.  This can then be tested and demonstrated to the customer.  If the product developed does not work due to technical problems or it is not what the customer wants, then this will be found out within the 30 day iteration and can be subsequently dealt with.  This is the opposite of the waterfall method, where it could be potentially a year down the line until you find out that your product does not work as expected or it is not to the customers needs. 

Also, Scrum can also cater for the ever evolving needs of the customer.  Code built using the waterfall method are often planned over a large timescale depending on the size of the product.  It may be, that by the end of development the customers needs have changed and therefore the product being developed may be obsolete and may need further development to get re-tailor it to the customers needs.  With Scrum, we can track changes and enter these into the backlog.  By evaluating and adapting, we can better tailor the product to the customers needs sooner rather than later.

Effective Story Writing in Scrum.

A major part of the Scrum Process is Story writing.  I decided to research the art of story writing so that I could improve my own story writing and hopefully improve the story writing capability of my team.

I discovered that all User Stories follow the same format.

As a <USER> I want <FUNCTION> so that <BUSINESS VALUE>

So as a Web based company, an example of a user story at my company could be: As a <NEW USER> I want to be able to <REGISTER> so that I can <USE THE WEBSITE>.

I then visited the Mountaingoat Software website for more information on story writing.  I found that they use an acronym to help users write better user stories. I N V E S T.  This stands for Independent, Negotiable, Valuable, Estimatable, Small and Testable.

Independent:

The story being written should not carry any dependencies.  This could lead to estimating and prioritization problems.  An independent story can ideally be worked on without the need to pull in any other stories in order to complete it.

Negotiable

Stories should have room for negotiation between the Team and the Product Owner.  They are not a solid contract but some room for requirement change should be available.

Value

The story being written must have some value to the users or customers, not the developers.  Stories should be written with the user or customer in mind.  The story should define what a user can do and what benefit this would bring to them if the story is implemented.  If there is no value to the customer or user, then the story should not be prioritized.

Estimatable

The Team should be able to estimate the amount of work that is needed to complete a story during estimation.  If the team are unable to estimate the story, due to ambiguity, the stories requirements should be made clear.  If the team are unable to estimate due to the size of the story, you will need to break the story down into smaller stories.

Small

Stories should be Small and relatively un-complex.  Large stories by nature seem to be complex to manage and more often than not are 2 or more stories combined.  Large stories should be split up into smaller stories in order to make them more manageable.

Testable

Stories should be in a testable against a predefined test case to verify that the story has been completed effectively.

Hopefully this will

The Ball Game

I attended my Certified Scrum Master training held by Tobias Mayer and Mike Sutton in September 2008. This was a brilliant course that had a practical element built in to help us learn. One of the practical elements was a game called "The ball game".

I have taken this from Mike Sutton’s Blog at Agile-Blogs. It is a great game and well worth trying with your team.

Timing: 20 minutes.
Ingredients:

  • People and space
  • about 30 balls (ping pong balls will do )
  • Stop watch
  • Flip chart to write down scores.

Directions:

  1. Form one big team
  2. Nominate a Starter.
  3. Nominate a Finisher
  4. Take 1 minute to plan how to score as many points during next round of play.
  5. Announce how many points the team will score during the next round of play.
  6. Play for 2 minutes (following the rules below).
  7. Repeat steps 1 to 6 , five times.

Rules:

  • Ball must have air time (a throw)
  • A player cannot pass to anyone directly beside or in front
  • Player can have only ONE ball in possession at a time
  • Dropped balls are discarded and returned to the container
  • Ball must go round all players and returned to the container to score a point.

Learning Points:

  • Demonstrate self organisation and iterative working.
  • Illustrate the ‘responding to change’ power of working in a highly collaborative and agile way.
  • Demonstrate the power of inspection and adaption and continuous improvement.

Devised By:  Boris Gloger

Taught to me by: Tobias Mayer + Mike Sutton

The Ball Game as played at the 2008 Fall Scrum Gathering in Stockholm.

The Sprint Planning Meeting.

Sprint Planning Meetings are held at the beginning of an iteration to plan the work that will be undertaken by the Team.  The Scrum Master, Product Owner and the Team, along with any stakeholders who hold an interest in any of the products being considered will be in attendance.

The Product Owner by this point will have groomed the Product Backlog, by this I mean he / she will have reordered the Product Backlog Items into a priority order.  Depending on the size of the backlog, the Product Owner may choose to only present the highest priority items to the team or depending on the Teams velocity, the items that fall within that figure.  The Product Backlog will then be presented to the team.

The Team will then have the opportunity to ask questions or ask for further information in order for them to gain enough scope so that the Team can go off and discuss what the work will entail.  My Team usually have the primary meeting to uncover which tasks will be considered for the Sprint and then take an hour to go discuss or mull over the items in their own time with no pressure to commit to anything right away.

The secondary meeting involves the Team planning which Stories they will move from the Product Backlog to the Sprint Backlog and theoretically committing to the work that they will carry out during the sprint (see image)

Sprint Planning

The Team will meet with the product owner to discuss what they feel they will be able to commit to during the sprint.  It may be that some stories that are of high priority are just to big to fit into the one sprint and may need broken down into smaller, more manageable stories or some stories of a lower priority may have to be completed in order for the higher placed stories to be worked on.  This will lead to negotiation with the product owner as to which backlog items will be added to the Sprint Backlog and once the Product Owner is happy with the commited list we can then go onto writing the tasks for each of the stories.

With the Sprint Backlog Items defined the Team will then collectively decide on a Sprint Goal.  A short sharp and to the point goal that the team will have reached by the end of the sprint.  The team will then aim to have obtained that goal by the end of the sprint.

Better Burndown Charts

I read a good article on how to improve your burndown charts. It also has one of the best analogies used to describe the Burndown chart that I have read.

 “As a pilot, I like to think of a burn down chart as being like the glide path of an airplane on final approach. An instrument in the cockpit tells you if are above or below the ideal glide path. If you are stabilized on the glide path (usually 3 degrees at a big airport) you will hit the runway at the designated touch down point. If you are too high, you will not make it to the runway unless you increase the rate of descent (which is not always easy to do). If you are too low, watch out for the trees!”

Well worth a read!

Toward Better Burndown Charts

Basic Burndown Charts

     The Burndown chart is a tool used to map the hours of work left to complete over time. It is a useful visual aid in tracking the team’s progress and is also useful for predicting when all of the work will be completed. 

     Each Iteration contains a list of prioritized stories from the Product Backlog. Each backlog item (story) contains a set of tasks. These tasks are all given a value representing how many hours it will take to complete the task. During the Daily Scrum Meeting the team will alter the value on the task by reducing the amount of hours if the task is near completion, or raising the hours if more work is needed to complete the task.  

     Part of the Scrum Masters job is to maintain the Burndown Chart.  I do this is by creating a spreadsheet that holds all of the stories within the iteration and the tasks held within the stories. After each Daily Scrum I update the number of hours left on each task in the spreadsheet and then plot the latest reading in a graph. This graph is called the Burndown Chart and is shown below. 

Burndown Chart

     The red line represents the total number of hours left in the iteration.  The number of hours is mapped along the Y axis of the graph while the number of days in the iteration runs along the x axis.  It is hoped that as the iteration progresses, then number of hours will decrease until it reaches 0. 

    The Burndown graph is a good tool for assessing the progress within an iteration.  If the Burndown chart does not seem to be burning down at a steady rate, it is burning upwards or is even flat-lining, this may mean that your team may be encountering something that is impeding them from completing their work.

    As you can see from my graph, I also map out each skill set within my group within the Burndown.  This allows visibility throughout the team of how the iteration is progressing.  This also means that as Scrum Master I can look out for any impediments that may be stopping the team from burning down effectively and try and resolve them.

    Now that you know the basics and what a Burndown chart is and what it is used for, look out for my next articles where we will dig deeper into the Burndown Chart.

Thanks

Allan

Retrospectives

A retrospective is held at the end of an iteration.  The Scrum Master will invite all members of the team (Product Owner, developers, QA etc) to a meeting to dicuss the successes and failures of the sprint.

Each member will discuss what went well and what did not go well in the Sprint that they have just undertaken.  These are then discussed by the team and any measures to make improvements on the failings of the sprint are discussed.  It is planned that the improvements will be implimented to make the sprint run smoother next time.

One main fear of mine is that Team members will see a retrospective as a negative thing.  A meeting that only the negatives are drawn and a place where people can vent their frustrations and blame onto other Team members.  This is not the case, the retrospective should be treated as a positive thing that will help the team by not only recognising the good areas within the team, but will aim to improve the negative areas rather than dwell on them.

I read an interesting article below which is based here:Retrospective Prime Directive

“One of the most obvious fears people have when first trying a retrospective is that the ritual will become a negative gripe session, interspersed with blame and counter blame.

Clearly such an event will not contribute to much learning.

The key to a constructive successful ritual is assuring that all the participants adhere to the Retrospective Prime Directive.

 The Prime Directive says:  Regardless of what we discover, we understand and truly believe that everyone did the best job that they could given what they knew at the time, their skills and abilities, the resource available and the situation at hand.

At the end of a project everyone knows so much more.  Naturally we will discover decisions and actions we wish we could do over.  This is wisdom to be celebrated, not judgement used to embarrass.”

The Retrospective Prime Directive is a good guide to follow. Working as part of a team means that you must trust and believe in your team mates abilities and that they will always give 100% to you and the work that they carry out. It is not fair to single out one member of the team to criticise and embarrass but try to think of ways to improve the team as a whole whether that be through reviewing actions and decisions we know we will be able to improve on should the same scenario arise again. This will make you stronger and more effective as a team.