How Scrum has improved our QA

I have worked at a web based startup company for the past 3 years.  Before we implemented Scrum just  under two years ago now, the QA team, of which I was a part of was a separate unit from all other teams.  We worked with the watrerfall method of development which meant we were involved in testing our functionality late on in the project.

One problem with this was that if the project was over running, then our QA time was cut and we had to work hard to make up the time lost in development by staying late on occasion.  This seems to be a common scenario with testing in the waterfall method.  Another scenario that I found was that the team became stuck in a rut with testing.  We became stuck in a rut of testing products in linear fashion that it felt as though every cycle was like groundhog day.

When we adopted Agile Development we had 4 main areas of expertise that were split into 4 main teams.  The ratio was around 1-5 (QA-Dev / Flash) and QA is part of the Scrum development team.  The Business side is driven by the Product team and our sprints are 2 weeks long.  This was the start of something new for our QA department.  Rather than being stuck at the end of the process, we were now included from the planning stage with Scrum.

We could now see the criteria being set down by the customer in the user stories that were provided to us by the Product Owner and any prototypes that were supplied. We now had an insight as to how the product should look and feel before the planning stage.

At first the planning stage was alien to us.  We had not been involved in any planning before with the waterfall method.  We had usually been given a product spec to write our test cases against before we were given the product to Test.  By the time we got our hands on the final product most of our tests were useless and had to be reworked. Being part of the planning stage felt as though we were now part of the team, rather than something stuck onto the end of a project to make peoples lives a misery.

Taking part in the planning meetings allowed us to gain a more in depth insight into what the product being developed would be expected to do.  Listening to both development sides to our teams plans on how they were going to code the functionality and how both Flash and .net would link together gave me an insight into any problems that may occur that could cause bugs in the code.   I would then be able to ask how I could go about testing these areas and include this in my test case.  This means that we are able to write our test cases earlier with the help of the User Stories and the developers.

Being part of the team during the development means that we are able to test earlier in the process. We have our own development environment which is updated regularly with new builds of the code base.  Once these new builds have been installed we set about testing them and raising bugs.  By testing against the criteria set down in the user stories and in our test cases earlier in the process, we can then find bugs early and have them fixed earlier thus meaning that we are not rushed off of our feet come the end of the iteration or the end of the project, had we been undertaking the waterfall method.  With this in mind QA can help in the process of “defining DONE” for each Sprint which helps to keep the project on track.

Overall I have found an improvement in our working practives by implimenting Scrum.  We have become part of a team rather than a seperate entity which helps us in our goal to try and have fully functioning software that is free of bugs.  Being involved in testing earlier in the project has helped break the ground hog day effect as with the nature of Sprints, we could be testing more than one product at the same time, so this can break down the boredom factor of working on the same product for a long time.  I have certainly found that our products have been going live with less bugs than before Scrum, so identifying these bugs earlier in the project has helped us.


The Mythical Product Owner Role

I was forwarded this article by a colleague.  It basically describes the product owner role and categorises the different types of product owner.  As a Product Owner could interpret their role differently depending on their ‘Day Job’ role it means that there can be different types of Product Owner depending on their role.

Take for instance, a product owner who works as a release manager, would be different to a product owner who works as a project manager.

It is an interesting read.

Scrum The Mythical Product Owner Role

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.


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.


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.


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.


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.


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.


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.

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


  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.


  • 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 ByBoris 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