Scrum Alliance or

This is a question I get a lot, what are Scrum Alliance and and which is “best”? The truth is there is no best, both have different certifications and a different business model. In this post I want to explain the differences between the two and help you decide which to choose. & Scrum Alliance Compared -

Let’s start with what they do. Both and Scrum Alliance offer training courses and certifications for Scrum Masters and Agile Professionals. Both offer a variety of courses for Product Owners, Engineers, and other professions but in this post I’ll focus purely on the scrum masters.

You can think of these organisations like Exam Boards, if you pass their exam you get a certificate which you can present to any employer and it will prove that you have a certain level of scrum knowledge. You can also show the badges off to your friends and family but personally I’d recommend against that. I spent half an hour explaining to my mum that a Scrum Master had nothing to do with Dungeons and Dragons…

Both organisations offer three levels of Scrum Master certification. For Scrum Alliance these are the Certified Scrum Master (CSM), the Advanced Certified Scrum Master (A-CSM), and Certified Scrum Professional Scrum Master (or CSP-SM). offers the Professional Scrum Master levels 1, 2, and 3 (more commonly known as PSM-I, PSM-II, and PSM-III).

Personally I hold the CSM from Scrum Alliance as well as the PSM-I and PSM-II from

Where these organisations differ is in how they go about granting the certificates. Scrum Alliance require you to attend a training course organised by a certified trainer. The prices of these vary depending on whether they are being held remotely or in person, which country they are being held in, and the level of the course. Typically in the UK you will pay around £700 for a remote course and £2000 for an in person one. Obviously the trainer then pays a fee onto Scrum Alliance. Once you have completed the course you will be sent a link to take the exam on Scrum Alliance’s website. If you pass (the pass mark is 37/50 questions) you’ll be awarded your certificate. also offer training courses. However, their courses are not a prerequisite to taking the exam. Personally I have never done a course, I simply logged onto the website and purchased the exam token. These vary slightly depending on level but the PSM-I exam is $150 dollars.

It is also worth noting that Scrum Alliance certificates expire and you will either need to attend another course or pay (about £30 I believe) to renew it every couple of years. certificates do not expire.

The next most obvious question is which is easier!? There is a general feeling that the exams are a little more challenging, however I’ve never seen any data to back this up. Personally I scored a couple of percent higher on the exam than the Scrum Alliance one however not enough to state clearly. If you’re looking for a simple answer on which one would be easier to achieve or which holds more market value then I can’t give that. I would say however that the PSM-II (and I assume the A-CSM) covers significantly more ground than the PSM-I and asks questions based drawn from personal knowledge rather than simply knowing the subject matter. There is a distinct step up in difficulty and, although I’ve never taken it I wouldn’t be surprised if the PSM-III was far more challenging again.

So there you have it, all the differences that I’m aware of between the two organisations. If you’re looking for a taught course with a certificate at the end then Scrum Alliance may be for you. If you’re interested in self study and funding then may be the better alternative however I’ve found that both are extremely high quality certificates.

Goals for 2021

As is the time for goals and be years resolutions I’m going to throw out a few of my own.

  • Read 21 Books
  • Write 52 Blog Posts
  • Pass my PSM1
  • Finish my new book
  • Finish painting my Stark and Lannister armies!

21 books isn’t that ambitious for me, although without knowing whether I’ll be commuting will cut into my audible time. The scrum master exam, yeah – I probably should have hit around to that years ago!

The book is top secret, well… unless you’re on Leanpub! But the blogging and painting will take some discipline.

Let’s see how it goes. Happy New Year everyone!

Growing Agile Teams at Agile Yorkshire

I attended Agile Yorkshire last week and saw two great talks by Tom Hoyland and Jon Fulton. I really enjoyed both but a few points in Tom’s talk really interested me and I’d like to take a few minutes to share them.

Tom is a Scrum Master at Sky Betting and Gaming, I’ve heard good things about the company in the past so I was interested to hear one of their success stories. It turns out that Tom was part of a team of twelve who really stripped Agile “back to basics” and conducted a series of experiments on the road to continuous delivery. Working in a regulated industry myself I was intrigued how they’d got on.

One of the first things Tom talked about was how many different people in the team came to the table with ideas of what was agile best practice. We all laughed at his “my guru is better than your guru” but it makes a lot of sense! I am heavily influenced by Jez Humble, Gene Kim, and Clarke Ching but many of my colleagues may watch talks and read blogs from very different thought leaders. Tom explained that one of the first thing they had to do in the team’s formation was break many of the concepts down to their fundamental concepts and understand what worked for them.

Something else Tom discussed was how the team consolidated their own backlog. This was not controversial, how else would you prioritise the work against it? It was only when he gave examples of some of the different backlogs they’re identified that I became intrigued. Risk Logs, Retro Actions, and Design Session – all of these moved onto the board and each became visible and prioritised.

It’s dangerous out there – take your buddy! I’ve heard many of the advocates or pair programming before but the idea of your buddy following you into meetings, design sessions, and CABs!? Tom explained that if your buddy went with you to these sessions not only would they learn how to design, and walk work through the CAB but they’d also know the current state of everything you were working on. If you were sick or the proverbial bus came along the team wouldn’t need to bother you because everyone would know what was going on.

group hand fist bump
Photo by on


There were many other good ideas (and I intend to borrow quite a few of them myself) but the final one I’m going to mention was the idea that Velocity is in fact a vanity metric (read The Lean Startup if you have no idea what I’m talking about). Velocity is just a number, like Number of Users or Number of Page Views). What we want are actionable metrics, like team predictability and accuracy of forecasts. As a Development Manager I frequently use the team’s average velocity to forecast delivery dates, Tom recommended that there are better measures out there such as a temperature check of the team’s current mood (which would often dip before any reduction in velocity). It’s an interesting idea, and one I intend to think more about over the next few weeks!

A big thank you to Royd and the guys who put Agile Yorkshire together each month. An equally big thank you to Tom and Jon for their great talks!

Learning the role of Scrum Master at the deep end

My induction into my informal position of Scrum Master was rather quick, a member of staff was leaving and the team needed someone to help run the meetings. Learning fast and jumping straight in at the deep end is my typical (if not favourite) way of learning so I rolled up my sleeves, read a few books and did my best.

So what have I learned? What dubious advise could I pass onto any developer who finds themself stepping into the same role?

Know your Ceremonies

The Scrum Master’s week is punctuated by meetings such as Daily Standups, Planning Sessions, Sprint Review and Retrospectives. You’ll encounter resistance to these because devs like writing code, they don’t enjoy spending hours each week sat in the meeting room. You’ll need to justify these sessions, if you can’t explain why you want to meet then it’s best not to!

Daily Standup

This is the most common session you’ll be expected to run. It’s also the most famous, many businesses claim to be agile simply because they have a daily standup! Getting it right is key to your team’s success.

First the obvious question, do you actually need to stand up? No! People who have never attended a standup will challenge this methodology, there are advantages for and against standing up for the meeting and you need to understand both sides if you want to discuss the reasons. On the one hand physically standing encourages participants to keep their part short and on topic, I also like to guide speakers around the circle so everyone knows when they will be expected to talk and no one is left stammering. On the other hand standing up can be very difficult for distributed teams, meeting over Skype with headsets reduces lot of background noise but brings with it the inevitable technical problems and opens the unending source of distractions which is a dev’s PC. There’s no right answer, but different teams will prefer one style or another.

Keeping on topic is a huge challenge and one I’m still struggling with. Your standup should consist of three bullet points

  • What did you do yesterday?
  • What are you aiming to do today?
  • Are you blocked in any way and are you on track to burn down?

In my experience there are two main reasons for a scrum wandering off topic, these are Story Telling (going into too much detail about what they did yesterday) and Problem Solving (using everyone’s time to try and become unstuck). Devs love to talk about challenges they overcame and solve other people’s problems. The key is to spot when this occurs and suggest that these conversations can be had later.

The sixteenth minute is an interesting idea, as I mentioned above one of the main reasons for scrums dragging on is people trying to utilise the entire team to solve their impediments. One approach is to formalise an optional follow up chat for the required parties so they can continue to discuss issues without hindering the rest of the team. Keep an eye on how many of these follow up conversations are needed, too many and they rapidly take over the team’s morning.

Sprint Planning

I’ve found the key to Sprint Planning is preparation, this can often be an issue when the meeting is scheduled for first thing on a Monday morning! Before you walk into the planning session you should have:

  • The backlog prioritised
  • Details of the capacity of your team (or team members if you plan individually)
  • Details of how much work has been carried over from the previous sprint

If you don’t have this information to hand you’ll need to acquire it in the meeting, this is all information you should have access to through your planning software. Asking for it in the meeting wastes everyone’s time and leads to boredom and the feeling of wasted time, not how you want to start your sprint!

Armed with this data your planning meeting is simply a matter of dishing out the highest priority tasks to the team members who want to pick them up. Simple!

Sprint Review

The purpose of the Sprint Review is to demonstrate what you’ve built to the stakeholders and other interested parties, this can often be your Product Owner, Support Team or other devs. These people then have the opportunity to provide feedback which can be considered, prioritised and included in the project.

The problem I often find is that there are so many ideas, so many discussion points and so many questions that your one hour slot is barely enough to get through the first demo. So how can we address this?

  • Nominate a single person to make note of the suggestions, by making sure everything is written down no idea is wasted and they can be prioritised and scheduled with your Product Owner
  • Consider recording videos instead of live demos, the live demo is a bane of any presenter. By asking your devs to record videos in advance the demos are foolproof, there are no unexpected technical problems and you know exactly how long each video will last!
  • Save questions and feedback until the end of each presenter. We are geeks, not public speakers, give your developers a chance by letting them get to the end before bombarding them with suggestions on how to improve the task they’ve been slaving over all week!

Sprint Retrospective

A fundamental part of the Agile Manifesto is that teams should look at what went well, what they’re struggling with and adapt their processes to improve. Often this is done in a retrospective meeting.

When I first started doing retrospectives we followed a well known pattern

  • What went well?
  • What didn’t go well?
  • What should we start?
  • What should we stop?

We worked our way around the table and everyone was expected to come up with a suggestion for each list. I found these meetings rather unfulfilling, I often felt they descended into a rant about process, other teams, technology or whatever else was irking the group at the time. While I’ve no doubt that it was good therapy I didn’t feel like the hour achieved much.

Instead I’d suggest planning each meeting with a specific topic

  • How can we ensure that high priority support requests are picked up mid sprint?
  • Should we use Web API or WCF for our new API?
  • How can we get clear acceptance criteria for our upcoming bespoke development?

By stating what you hope to achieve from the retrospective in advance you stand a much higher chance of success! Ask your team for items they want to discuss, email around your proposed meeting topic with plenty of notice and ask your devs to bring their own ideas to the meeting.
Hopefully I’ve given a few helpful suggestions for you to consider. I don’t claim to be an Agile expert and I’m still struggling to follow lots of my own advice but every sprint we learn a little more… Isn’t that the point after all!?