Tag Archives: Scrum

QA – Creating a high performing QA function

Posted on by
Reply

Two years back I was asked to put together a presentation on how to create a high performing QA function for a large financial company who were considering an Agile transformation.

The presentation touches upon all aspects of Agile; process and practices. It covers continuous integration, continuous delivery, test automation, Scrum process, defect management, etc…

Though the presentation below does contain some specifics to the actual company, it does have a lot of reusable content that you may find useful when evaluating your own company QA function needs within your Agile implementation.



Recently I had the pleasure of working with Gareth Waterhouse, he has an indepth knowledge of testing within an Agile environment as well as a very strong knowledge of test automation and I would highly recommend visiting his blog for everything about QA within an Agile development team.

Quick, Intuitive, Simple Scrum Tools

Posted on by
Reply

Scrum WallI have had lots of people ask me which software I use when running their Scrum ; TFS, OnTime, Jira, etc. All have their merits, but my personal favorite, is a wall with different colour post-it notes and some black tap.

My problem with software tools are that they over complicate the process, not having a wall also means a lack of instant visibility to the PM and stakeholders, something I promote (I like the business walking up to the wall and seeing the flow of work. Having the wall also self-promotes Scrum.)

To supplement my Scrum wall I use a simple Excel spreadsheet which generates my burndown chart and tracks progress. I will post up my template tomorrow spreadsheet tomorrow.

Below is my current SCRUM wall, I use different colour cards to acknowledge different task types (Green – Product Backlog, Red – Developer Task, Yellow – Tester Task, Orange – Impediment);

What a Scrum Master is and what they are not…

Posted on by
Reply

Over the years and the companies I have worked with, the most misunderstood role within the Agile sphere has been that of the Scrum Master. Out of the various companies I have worked for, only 2 have had a good grasp on what the role is.

To help clear up the definition of what a Scrum Master is, I thought I would list out what a Scrum Master is to the team and what they should not be;

What is a Scrum Master;

  • Facilitator / enabler
  • A referee of the Agile processes / practices
  • An impediment remover
  • A change agent / champion
  • Protector of the team
  • Motivator
  • Metrics owner
  • Coach – Its not just Agile Coaches who can coach. I am both; an Agile Coach and Scrum Master, I can do both and I feel that a good SM / AC are fore-filling both roles

What a Scrum Master is not;

  • Part of the team – This one is often a bone of contention. A Scrum Master is a slave for the team, if you hold them accountable for the team not meeting their commitment you will drive all the wrong behaviors. Your Scrum Master won’t want to take a kicking for a developer not cutting code or check-in code that broke the build on your CI environment, so they’ll start forgetting about being a Scrum Master and start cutting code, writing unit tests, etc… (I’m lucky that I was a developer, remember most Scrum Masters are NOT techies)
  • A team member wearing the ‘extra’ hat of being a Scrum Master – This applies pressure on the person if they have two conflicting needs; for example a developer needs to finish some code so the team meets their commitment but at the daily update a major impediment that also jeopardises the commitment needs resolving but the developer cannot manage to do both before the end of the Sprint.
  • Wearing both PO and SM hats – Self validation jeopardises the integrity of the SM role
  • Determining the priority stack – Being a product expert is a full time role
  • Responsible for the distribution of the backlog amongst the team – The team are responsible for selecting the backlog to play. If your Scrum Master distributes the work this dilutes the teams collective responsibility of delivery.
  • A project manager, development manager, team manager, delivery manager, release manager etc… - Though there have been times when I have had to lead, a Scrum Master should not be looked to as the ‘leader’ of the pack; if you notice the team look at the Scrum Master when giving their daily updates, try sitting behind them or deliberately not attending the daily Scrum every now and then.
  • Responsible for delivery – Often the one that messes with Senior Managers the most. Scrum Masters are there to assist the delivery, they are not the person who cuts or tests code, therefore they are not in control of the teams destiny. Scrum Masters need to be clear to the team that they will help how ever they can, but if the team fails to deliver its on their own heads be it.

The Testing Curve

Posted on by
Reply

Following on from my post, Testing in Scrum / Sprint, I wanted to share with you a diagram I have used many times to help explain why testing must start as soon as possible within a SPRINT and why it is important that task cards are testable as a self entity (Unit test).
It is incredibly important that teams do not have ‘Epic’ task card’s included within their SPRINT, as this possibly hinders the ability of a tester to start testing early, as the ‘Epic’ wouldn’t become testable until development is complete, hence delaying the test phase.

Note: I include an initial ‘peak’ to allow for testers writing up their test scripts

Agile Testing Curve

The unhealthy testing line has a tidal wave at the end of the SPRINT, unlike the nice calm waters of the healthy testing curve. Tidal waves should be avoided at all cost, as you run a greater risk of failing a SPRINT; the tester may not be able to complete all the testing within the time period and more than likely the QA will be compromised due to the pressure on the testers to pass a release as shippable.

If you see a very calm testing period at the beginning / middle of your SPRINT, be careful this may be the calm before the storm!

Difference between a user story and a story

Posted on by
Reply

A user story defines the requirements of the business and is written by the PM along with a BA (if available / possibly the same person), the user story is then broken down into individual stories that can be delivered against, which in turn is broken down into individual tasks.

Sounds simple, but in practice it is often not achieved. If you don’t break down User Stories you’re always working against Epic scale stories. It is critical to break down user stories into multiple stories so that each story is deliverable within an iteration (or if using Kanban ensures it can fit into the swim lanes).
It is important to break down stories into tasks so that you have a clear vision of what needs to be achieved to deliver the story. Having tasks also allows us to understand during an iteration how much time is remaining. Story estimations are finger in the air stuff, in particular if you are using relative points as your measurement, task hour / day measurements helps us to understand the actual remaining time against the original story estimation. Long term this will help improve your team’s ability to better estimate both user stories and stories.

On a side note, even though acceptance criteria is only a must have for user stories and stories, I also encourage teams to have acceptance against a task. Doing this increases QA throughout the whole of the process.