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.




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.

Scrum definitions explained

Scrum has a lot of terms used to describe specific parts or roles that are used from day to day.  This sometimes confused people and daunts them when they hear a term that they don’t understand.  Some are easy to relate to, but some are pretty obscure.  So if you don’t know your Pigs from your Chickens… Read on 🙂

Average Velocity

     The number of points completed in each of the Team’s Sprints divided by the number of Sprints completed.

Burndown Graph.

The trend of work remaining across time in a sprint, a release, or a product.  The source of the raw data is the Sprint backlog and the Product Backlog, with work remaining tackled on the vertical axis and the time periods (days of a sprint or sprints) tracked on the horizontal axis.


     Someone who is interested in the product but does not have formal Scrum responsibilities and accountabilitys (is not a Team Member, Product Owner, Scrum Master or other stakeholders).  Chickens can attend Scrum Meetings, but they must not speak as they are not part of the team.

Daily Scrum Meeting

     A short alignment meeting held daily by each team during which the team members synchronize their work and progress and report any impediments to the Scrum Master for removal.  Dependencies on other scrum teams can also be reported here in order for the Scrum Master to try and deal with before they become an impediment.

Estimated work remaining

      The number of hours that a Team member estimates remain to be worked on any task.  This estimate is updated at the end of every day the sprint backlog task has been worked on.  The estimate is the total estimated hours remaining, regardless of the number of people that perform the work.


     Product functionality that is developed by the team during each sprint.

Increment of potentially shippable product functionality

     A completely developed increment that contains all of the parts of a completed product, except for the Product backlog items that the team selected for the sprint.


     One cycle within a project.  In scrum, this cycle is 30 sequential calendar days or a Sprint.  Companies can tailor this to their needs.  We currently use a 14 day Sprint.


     Someone occupying one of the three scrum roles (Team member, Scrum Master or Product Owner) who has made a commitment and has the authority to fulfill it.  Just like a real life pig, who likes to get dirty, think of the members of your team who like to get their hands dirty completing the work.  Compare this with people not in your team who wont be getting their hands dirty, they are known as chickens.

Product Backlog

     A prioritized list of project requirements with estimated times to turn them into completed product functionality.  Estimates are in days and are more precise the higher an item is in the Product backlog priority.  The list evolves, changing ad business conditions or technology changes.

Product Backlog items.

     Functional requirements, nonfunctional requirements and issues, which are prioritized in order of importance to the business and dependencies and then estimated.  The precision of the estimate depends on the priority and granularity of the Product backlog item with the highest priority items that can be selected in the next sprint being very granular and precise.

Product Owner

     The person who is responsible for managing the product backlog so as to maximize the value of the project.  The Product owner represents all stakeholders in the project.


     Not an acronym, but mechanisms in the game of rugby for getting an out-of-play ball back into play.

Scrum Master

     The person who is responsible for the scrum process, its correct implementation and the maximization of its benefits.  All round genius 🙂


     A time-box of 30 sequential calendar days during which a Team works to turn the Product Backlog it has selected into an increment of potentially shippable product functionality.  This means that a team must aim to have potentially releasable software by the end of their sprint.

Sprint Backlog

     A list of tasks that defines a Team’s work for a sprint.  The list emerges during the sprint.  Each task identifies the story being worked on, those responsible for doing the work and the estimated time remaining on that task on any given day during the sprint.

Sprint Backlog task

One of the tasks that the team or a Team member defines as required to turn committed Product Backlog items into system functionality.

Sprint planning meeting

A one-day meeting time-boxed to 8 hours that initiates every Sprint.  The meeting is divided into two 4-hour segments, each also time-boxed.  During the first segment, the Product owner presents the highest priority Product Backlog to the team.  The Team and the Product owner collaborate to help the team determine how much Product Backlog it can turn into functionality during the up and coming Sprint.  The team commits to this Product Backlog at the end of the first segment.  During the second segment of the meeting, the Team plans how it will meet this commitment by detailing its work as a plan in the Sprint Backlog.

Sprint Retrospective Meeting

A meeting time-boxed to 3 hours and facilitated by the Scrum Master at which the Team discusses the just-concluded Sprint and determines what could be changed that might make the next Sprint more enjoyable or productive.

Sprint Review Meeting

     A meeting time-boxed to 4 hours hours at the end of every Sprint at which the Team demonstrates to the Product Owner and any other interested parties what it was able to accomplish during the Sprint.  Only completed work will be demonstrated.


     Someone with an interest in the outcome of a project, either because he or she has funded it, will use it, or will be affected by it.


     A cross functional group of people that is responsible for managing itself to develop software every Sprint.


      A period of time that cannot be exceeded and within which an event or meeting occurs.  For example a Daily Scrum meeting is time boxed to 15 minutes and terminates at the end of those 15 minutes regardless.

Taken from “Agile project Management with Scrum” by Ken Schwaber with some personal touches by myself 🙂


The importance of the Sprint Review Meeting

The Sprint Review meeting is an important part of the Scrum process.  Its not only a platform to showcase your work, but a place to place to invoke discussion with the stakeholders on the product that you are creating.  It also helps keep the project on the right direction as it ensures that the customer can view the progress earlier in the process rather than at the end of the project where it is too late to make changes without the project over running.

The Sprint Review should be the culmination of meetings by the product owner with the customer where product specifications have been hammered out between the two and given to the team to build.  Any deviations from this specification must have been relayed by the Scrum Master to the Product Owner and thus onto the Stakeholders for approval as to avoid any embarrassing situations in the Review where the product does not seem to meet the requirements of the customer(s).

The Sprint Review is often the first time that the stakeholders set eyes on what the Scrum Team have been working on in an iteration.  The team start by stating their overall scrum goal that was determined in the Sprint Planning Meeting at the start of the iteration.  Ideally the team would have completed each backlog item that was brought into the sprint at the Sprint Planning Meeting but it is more important that they have completed their overall goal rather than completing all stories.

The team will then demonstrate the functionality of each user story or new piece of functionality to the Stakeholders.  As we are a development group of a web based company, not all of the stakeholders can be in the same room at the same time, so we counter this by sending out the location where our new functionality is held for the stakeholders to access.  We then communicate with each other through conference call or Skype to demonstrate the product, giving the stakeholders a more hands on approach as they are able to ‘play’ with the product.

It is often at the end of the review where questions are asked of the product by the stakeholders and refinements can be planned by the team.

When I inherited the role of Scrum Master of my team the Scrum Master and the Product Owner had not been holding the Sprint Review meeting.  There had been one meeting where the product that the team were demonstrating was not fully functional.  There were some known bugs in the code and these were demonstrated at the meeting.  The meeting was not productive and morale within the team towards the Sprint Review meeting was low.

My first main role as Scrum Master of my team was to facilitate the construction of a large piece of functionality that had a lot of back end and front end work.  At the beginning of the project the functionality that we were constructing was not deemed to be reviewable and we did not demonstrate the work to the stakeholders.  Over the following iterations we were not having a regular review meeting with the stakeholders, which was against the rules of scrum.  We had found ourselves working hard to get the stories completed and we had gotten into the mid set that time would have been wasted by having a review meeting if the customer could not see anything.  We will put this down to inexperience on my part 🙂

I then attended a Certified Scrum Master course held by Tobias Mayer and Mike Sutton held in London.  Both stated that the great need to have a review meeting to not only showcase your work, but to make sure that it was heading in the right direction.  I returned to the office vowing to have regular Review Meetings from now on.

The first review meeting that we had was towards the end of production on our product.  We showcased our work and were met with some change requests.  Some were thought to be fundamental and may push us over our deadline.  We managed to make the changes and have our product out a week past our deadline.  If we had held regular review meetings, we could have caught these change requests earlier in the process and put them right.

The team has now moved onto their new project.  We recently had our first Review Meeting with the stakeholders.  The meeting went well, the stakeholders were happy with the progress we have made on our new product and the team are happy that they actually have some good feedback which was a morale booster.

I cant emphasise enough the value of the Sprint Review Meeting it helps keep everyone focused and happy.  Compared with the waterfall method of reviewing the product at the end of the lifecycle, the process of regular reviews could save you from a horror scenario at the end of the project when you find out it is not what the customer wants.

Thanks for reading.


Our Daily Scrum Meeting.

I thought I would make a first attempt at writing about the experience that I have with Daily Scrum Meetings.  The company I work for has been practicing Scrum for over a year now.  We see the Daily Scrum meeting as an important part of the Scrum process.  The meeting, scheduled for all members of the team is time-boxed to 15 minutes.  The 3 important questions that each team member must answer are:

  • What did you do yesterday?
  • What did you do today?
  • What blocking issues (impediments) do you have?

From these 3 questions the Scrum Master and the Product Owner can ascertain how the team are progressing and if anything is blocking the team from reaching their sprint goal.

I inherited my role as Scrum Master of my team when the previous Scrum Master left his role in the company.  The team were already functioning as a well oiled unit, but were using the daily scrum meetings to show their progress on a story by story basis.  This seemed to please the Product Owner as it showed real progress with work being completed within the story. 

During the daily scum meetings that followed I found that this method encouraged one person to be the spokesperson for that story even if 2 or more people had been working on it.  The team member would explain the progress made on the story to the group, explaining what had been done, what they were going to do and what impediments they had.  I found that using this method meant that team members could realistically not say a word on their progress at a scrum meeting and leave all of the speaking to the person explaining progress.

This worried me.  Not only could team members avoid speaking at the scrum meeting but we could be overlooking some serious impediments that could block us from reaching our scrum goal.  

I decided to revert back to the 3 question method as I felt that this would benefit the team in the long run.  Each team member now has a role within the scrum meeting, stating what they did yesterday, what they are doing today and any blocking issues that they have.  I have found that the team have really reacted well to the change in method team members who before would have happily taken a back seat have become more confident in stating what they have done and what they are doing and we have uncovered more blocking issues earlier in the process than we would have before.

After reading this article by Mitch Lacey Fourwarned is forearmed, I decided to add a forth question to the daily scrum.  The forth question is “How likely are we to complete this story by the end of the iteration”.  We then mark the story cards with a green dot if we think we will be finished by the end of the iteration and a red dot if we think that we wont be finished.  This allows the team to cut past the surface issues that the scrum meeting produces, yes, we may be making good progress on completing tasks on the scrum wall, but will we be able to complete the story?  This question allows the team to state how confident they are on completing the tasks thus completing the story.  This allows us to plan our stakeholder demonstration meeting easier.  We will then use this information to choose which areas are suitable to demonstrate and which areas will be available for demonstration at next iterations demo.  This will theoretically prevent us from showing the stakeholders functionality that does not work and thus saving us from some heartache ( or headache, I’m not sure :D).

I sometimes think that some people take the 3 question rule for granted, but it is not until you start using it that you find it is an efficient tool for gauging progress from all team members and anything that will block your progress towards your scrum goal.