Retrospective Experience – Halloween Special

The end of the sprint was approaching and I was researching which technique to try next, when I saw this tweet from @aaronjmckenna which I had to try:

Thankfully the team are used to the 5 stages technique so after getting some speakers from IT, queuing up a few spooky songs and introducing the theme, we plowed head first into it.

Stage 1 – Setting the Scene – Halloween Treats

Each team member should think of a Halloween treat to describe how the last sprint went

As with all first stage techniques, this was great at getting every single member of the team to talk at least once and generally wake people up. We had some nice friendly banter at weird definitions of treats, so the team were set for the next stages.

Stage 2 – Gathering Data – Ghost Stories

Each member of the team had to come up with a scary story (which could have a happy ending) describing a key event in the last sprint

This was probably the least successful part of the retrospective as only a small number of team made an actual story. That’s a problem with either my explanation or the team, not the technique, and we still ended up with a decent set of views.

Stage 3 – Generate Insights – Trick or Treat

Each member of the team had to come up with 1 treat (something that will help improve the team) and 1 trick (something that is or could hold us back)

This worked really well as it limited everyone to just one idea. As you can see below, I also decorated the board:

Trick Or Treat Board
Trick Or Treat Board

Stage 4 – Decide what to do – Pick a Door

The team had to decide which doors to visit to talk about, aka dot voting

Stage 5 – Closing the Retrospective – Spook of the Sprint

Each member of the team had to thank one other member for something they did in the last sprint.

I must admit, we don’t normally do much for this part of the retrospective and we certainly don’t do anything as gushy as thanking each other, so I was a little skeptical!

I could tell by the audible groans from the team that they thought the same thing when I introduced the idea, but I’m pleased to say it was quite a positive thing. What’s more, we now have a wonderful mascot for the next sprint.

Sprint Mascot
Sprint Mascot


All in all, this was one of our better sprint retrospectives and I really like using a theme. Aaron’s idea of timing each thinking section with a song worked fantastically, so I’ll be looking to do that again.

I’ll also definitely be keeping an eye on his blog for any future themes to try.

Personal Retrospective

What went well?

  • The limit of 1 good thing and 1 bad thing helped focus the team. I’m not sure I would use this for every retrospective as it’s nice to let the team vent, but it’s a good way of getting to the most important matters.

What could I have done better?

  • Given more time (and courage) it would have been nice to decorate the room a bit more;
  • I’m not convinced I summarized the stories from the second stage clearly on the board, or even guided the team to use these as a basis for the next step. I think I’ll try and get the team to come up with a summary statement next time, rather than something only I understand.

What should I not do again

  • Talk about writing a blog post over a week before having the time to do it!

Sprint Planning Technique – Group Sorting

Do your sprint planning meetings contain a lot of disagreements and arguments? Are you spending more time trying to decide how many points a PBI is worth than it would take to develop it? Don’t worry, you’re not alone.

To combat this, my current team tried a technique which worked really well. Not only did the meeting take less time than normal, but more of the team were engaged and every team member was happy afterwards.

I’m sure this has an official name, but I’m going to call it “group comparison” until I find out what that is. Thankfully it’s really simple.

Step 0 – Prepare

Hopefully you’re performing some sort of backlog grooming so this is relatively quick. If you’re not, this planning technique might help, but I strongly encourage you to schedule a regular grooming session. We do 1 hour every 2 week sprint and it seems to be enough. YMMV.

Print out (or create on Post-It notes) the PBIs that you think the team will be able to commit to. I’d suggest a little more than your velocity after taking into account capacity.

From your planning poke decks, place the cards on the table that match the size of PBI your team can normally deliver in a sprint in a line. For us, this was 1, 2, 3, 5, 8.

Step 1 – Introduce the PBIs

This is simply refreshing the minds of all the team members so they know what all the PBIs are.

Step 2 – Split the team into groups.

We split into two groups, but I guess you could do more. Basically, each group is invited to come up to the table one group at a time and sort the PBIs under the poker card they think that PBI is.

Step 3 – Invite the other teams

Once the first team has finished, invite the next team up. Second and subsequent teams should check the previous grouping. If they disagree with a position of the card, move it to where they think it should be. The team should mark each card with a dot to show that it’s changed.

Repeat this step for each group and – excuse the hideous use of paint – something like this:

End of sorting by size
Fig 1 – Table after grouping PBIs into story point buckets

Step 4 – Discuss any significant changes

Once all the teams have finished, invite everyone back to discuss any cards that have moved twice, i.e. have two dots. It doesn’t matter if they’ve moved from 3 to 5 and back to 3, just discuss them so the group can have a consensus.

Step 5 – Write the story points on each card

Once that’s finished, there should be some sort of agreement to the size of the PBIs, so write the story points on the cards. This step is really important as we’re about to move them all around!

Step 6 – Order by dependencies

Ask the whole team (or a subset if you’re a really large team) to order these by dependencies . We used a column for each chain of dependencies and staggered them if there was some overlap, i.e. shared parents.

PBIs ordered by dependencies
Fig 2 – PBIs ordered by dependency

As you can see in the above image:

  • PBIs 1, 4, 6 and 7 were marked, and the team discussed 1 and 7 further;
  • PBIs 1, 6, 4 and 5 have no dependencies so can be started at any time;
  • PBI 7 has a dependency on PBI 4;
  • PBI 3 has a dependency on PBI 2;
  • PBI 2 has a dependency on both PBI 1 and PBI 6.

Step 7 – Mark Dependencies

By now, the PBIs should be sorted not only by size, but it should also be clear which are dependent on another PBI and which are standalone. Simply write this information on each card ready to transfer to your tool of choice.

Final Step – Task Breakdown

Perform you’re task breakdown as normal and you’re done.

It’s important to note, that the team can change their mind about something half way through. Just because a PBI started step 5 as 8 story points and dependant on another one, doesn’t mean it needs to end up in that state.


Once you’ve completed this, you should have a sized and sorted set of PBIs ready to be committed to and placed in the sprint backlog. If it’s anything like us, you’ll see the following benefits:

  • You score PBIs much quicker
  • The PBIs are scored relative to each other
  • It’s easy to work out dependencies
  • MUCH less arguing
  • MUCH more team engagement

The only downside I can see, is that it’s possible for the business priorities to get lost in the re-shuffle. As this is limited to just the sprint and you’re going to deliver them all, it’s not a problem.

Retrospective Experience – High Performance Tree

For this retrospective, I was struggling to pick an appropriate technique. The team’s velocity has been creeping up and the actions from each retrospective were mostly minor tweaks. So I hit the books and saw this in the “When you would use this exercise” heading of Luis Gonçalves and Ben Linders Getting Value out of Agile Retrospectives book chapter on “High Performance Tree”:

“A good team that is looking for the next step to become a high-performing team”

Clearly that sounded perfect, and after a little more digging I found a fantastic video by Lyssa Adkins called The High Performance Tree which demonstrates the technique perfectly.

Gather Data, Generate Insights and Decide What To Do

I was a little nervous about using the metaphor as it’s not something we’ve done before and I’d read that the team can get a little uncomfortable. Thankfully that didn’t happen at all.

I won’t re-iterate the steps, or embarrass myself by including a photo of the “tree” I drew, but I will say that each root, leaf and fruit led to really interesting discussions. Having a visual representation of our target worked really well. It helped guide the conversation towards parts we are missing, but also towards part we are doing well.


I can’t list all the outcomes, but I’m particular pleased we realised we don’t currently have a “can do anything” attitude but perhaps should. I’m really hoping we can turn that around in coming sprints.

Overall, this was a great technique and we had an excellent retrospective. If you’re a ScrumMaster of a mature team and are looking for inspiration to become high performing, I’d definitely recommend this technique.

Personal Retrospective

What went well?

  • My drawing of the tree!
  • The team responded well and it was good to go back to first principles

What could I have done better?

  • When writing up the meeting, I noticed a few points that we said we’d get back to, but didn’t. I need to come up with a better way of tracking these points.

What should I not do again?

I don’t think anything went so badly that I can put in this category.

Retrospective Experience – 6 Thinking Hats

To make the team think a different way during the retrospective I decided to try 6 Thinking Hats. We’re used to saying what went well and what didn’t, so I thought this would be a good way to get some different discussions going.

I was a little nervous beforehand as the description warns about something I’ve been struggling with in previous sprints, namely facilitating rather than controlling. So at least the technique forced me to deal with that head on!

“Tip: The facilitator should try to stay out of the circle and try to avoid the participants talking directly to them”

I was also a little worried that I was flooding the team with lots of new techniques, so we used ESVP as a check-in exercise like we did a few sprints ago. This not only did the job of getting everyone off their feet, but we had a much better split of positive over negative categories this time, so it gave me a nice boost too.

Gather Data, Generate Insights and Decided What To Do

Things started slowly as we didn’t really know what we were doing (see Personal Retrospective below) and we’re not used to Blue hat thinking, but once we got onto topics we felt comfortable with the meeting progressed well.

I found facilitation to be quite hard to begin with, as it seemed like the team were stopping to see what I wrote on the board, but again, that seemed to improve as time went on.

Finally, I won’t go into the actual details, but the meeting ended on a really positive note and there seemed to be a real air of optimism for the next sprint. It will be interesting to see if that’s something this technique brings, or we just had a good retrospective. It was certainly more noticeable than previous retrospectives, but that could be coincidence.


The exercise started slowly with the team talking directly to me, but as things progressed and we got onto topics we’re more comfortable with – what went well, what went badly – time started to fly.

I’m lucky as I have several strong characters who are more than willing to lead such a debate (which could be a bad thing if they dominate), but if I didn’t, I’m sure there are ways around that.

Overall, I think it’s a good exercise to conduct and one I’ll certainly use again.

Personal Retrospective

What went well?

  • The team produced some good insights, which is a good sign we can become more self-organising;

What could I have done better?

  • A team member mentioned that the strictness of the hats meant he couldn’t/didn’t say something when he thought of it and then forgot. I could provide pen and paper or perhaps tell everyone that than anything could be mentioned and if it’s not allowed we’ll note it for later;
  • I don’t think the time slots of 10 minutes needs to be a strict rule. Next time, we’ll treat it as a time-box, rather than “we must talk for 10 minutes”.

What should I not do again?

  • I’m not convinced I explained the hats particularly well, so next time I’ll try to give examples of each before starting the exercise.
  • Related to that, I didn’t use the results from the previous hats to guide the conversation for subsequent hats particularly well. During the write up I noticed a few facts we didn’t discuss.

Retrospective Experience – One-Word with Marmite Voting

The last couple of retrospectives – “ESVP, Sailboat and Constellation” and “Self-Assessment and Circles and Soup” – had much larger scopes than you’d normally use. So for this retrospective I wanted to bring the scope much tighter and concentrate on what you’d normally discuss, i.e. the last sprint.

Stage 1 – Set the Stage

As usual, the team recapped the last retrospective and went through the progress made on the previous actions. It was great to see some of the team calling me out on not following up on some of the actions I had. They’re not only paying attention, but they also care. Perhaps one day I will make myself redundant and the team will be truly self-sufficient!

Perhaps one day I will make myself redundant

As we’d all just had a nice long weekend thanks to a bank holiday Monday, I wanted the check-in to get the team talking. So I used a slight variation of One-Word where we split into two and were tasked with saying the one-word your partner would use to describe the last sprint.

I time-boxed that to 10 minute discussion, and I’m pleased to say it worked rather well. As expected the words chosen were on the negative side, but it achieved the engagement I was looking for and woke everyone up.

Stage 2- Gather Data

To gather data, we used a technique I read about called Marmite Voting​. I created 8 pre-written topics and each person in the team is asked to rate their feelings between 0 (“HATE IT”) to 10 (“LOVE IT”).

Stage 3 – Generate Insights

I collated the results of the Marmite Voting and wrote up on the board the scores. We then discussed as a team what we thought each score meant, i.e. why it was low, are we suprised by that score, what does it mean.

As an example we realised that using technology X is new and therefore slow going (as the scores were low when asked if we liked using it), but we should try and stick with it (as the scores were high when asked if we thought the team/project would benefit in the long run).

Stage 4 – Decide What to Do

As I only asked 8 questions, we were able to discuss the low scoring topics thoroughly and come up with ideas to raise the scores next time.

Stage 5 – Close

I thanked the team for their hard work and ideas produced so far.

What went well?

  • I realized the team were feeling a bit lethargic and used a Check-In exercise that got all the team involved.
  • Marmite-Voting is pretty good when you have a clear question you want answered.
  • It was great to realise the team didn’t particular enjoy using a new technology but could see the benefits. This really focused us towards tweaking the way we use it to hopefully make things easier.

What could I have done better?

  • I don’t think I explained the One-Word variation particularly well as some of the team members had blank faces for a while. (Although the subsequent laughter at me explaining it badly for a second time certainly woke some of them up)
  • I might consider asking the product owner (or perhaps even other team members) if there are any topics they want discussed the next time I do Marmite Voting.

What should I not do again?

  • I think I led, rather than facilitated the Generate Insights part of the retrospective. Perhaps that isn’t a bad thing, but I think my voice was over used.

Retrospective Experience – Self-Assessment plus Circles and Soup

After recapping the previous sprint retrospective actions, where I’m pleased to say we made a handful of small improvements, I introduced the team to the notion of team self-assessments. We all agreed it was worthwhile, so completed SAFe ScrumXP Self-Assessment which despite some disagreements took about 15 minutes.

I won’t share the result, but it’s nice to have a baseline and have clear indication of places we need to improve. We will definitely be repeating this exercise in the future.

We then proceeded through the 5 stages of a retrospective.

Stage 1 – Set the Stage

I noticed in the previous retrospective – see Retrospective Experience – ESVP, Sailboat and Constellation – that there were a lot of negative comments about things we really didn’t have control of. I was therefore worried that this was going to be another negative retrospective and although it risks going against the advice:

“It is extremely important not to use a retrospective to identify purely negative parts of a project”

I thought I’d give a broad context of “anything goes”! I had some positive points up my sleeve, so I decided the risk of focusing on the negative was worth it.

Stage 2- Gather Data

The team split into pairs (with one group of 3) for 15 minutes to discuss the various topics they would like to raise.

Stage 3 – Generate Insights

As I was expecting a lot of negative comments, I decided I’d use a technique I’d recently read about called Circles and Soup. This categorizes all the points raised into the following groups:

  • The team have direct control over so can take direct action
  • The team have influence, so their action would be a persuasive, influencing or recommending action
  • The team may have no control or influence, but they can choose actions for how to respond collectively when they find themselves swimming in the soup​

I was hoping the team would then be able to get some closure on the things out of our control and subsequently put less thought into.

Stage 4 – Decide What to Do

After the groups presented their points to the rest of the team, we then used Dot Voting to pick out the points the team thought were worth further discussion. We then took the top 5 most voted for things and brainstormed some solutions that we could try. It’ll be my job over the coming sprint to make this happen.

Stage 5 – Close

I thanked the team.

Personal Retrospective

The team didn’t produce anywhere near the number of negative comments I thought they would so I’m not convinced Circles and Soup was the best technique to use. It was definitely worth trying, but I think it would be nice to apply this technique once you knew there were a lot of negative things being mentioned, rather than doing it regardless.

What went well?

  • Individually the Self-Assessment and the Circles and Soups worked well.
  • We identified a few team worries about external factors that we can think about and prepare for.

What could I have done better?

  • I should’ve researched and explained Circles and Soup better. I thought it was a self-explanatory technique, but after introducing it to the team, it was clear that it wasn’t. As I couldn’t explain it simply also shows I didn’t fully understand it! I should stop assuming these things are simple and/or the whole team are as keen as me!
  • I distanced myself from the team discussion, so had no idea of the issues being raised. If I was more involved, even if it was just observing more closely, I could’ve swapped out Circles and Soup for something else.

What should I not do again?

  • Although I’ve been acting as ScrumMaster to the team for 18 months, using these types of techniques is new to me. As such, I don’t have the confidence to swap out techniques on the fly. That should come with time though, so I’m not beating myself up about it. Time will tell.
  • Another sign of my inexperience is that I’m too keen to try out all the new techniques I’ve heard of! I’m not convinced doing both a Self-Assessment and a “normal” retrospective is right. I’ll need to read more into this.

Verify WordPress Backups Using Azure

I suffered some minor data loss today which I managed to restore from backup, but not before a few minutes of “why can’t I restore”. It reminded me of the classic quote:

“Backups always succeed. It’s restores that fail.”

I then realised that although this site is backed up via the excellent UpdraftPlus Backup / Restore / Clone plugin for WordPress I’d never tested the backup.

So, I did some digging and it seems the general advice is to see if you can open the zip file the backup process produces. Now call me a skeptic, but that makes me a little uncomfortable. Restoring on top of this site (shudder) or restoring to a sub-domain was also unappealing and then I remembered Azure.

I’m lucky enough to have a MSDN subscription which gets me some free Azure time, but there always seems to be free trials out there. Once I was logged into the management portal the process was very simple. Click New -> Compute -> Web Site -> From Gallery -> WordPress and fill out the following two dialogs:

Azure Create Website 1

I didn’t bother filling out the “Deployment Settings” section as I would be deleting the site as soon as I was done.

Azure Create Website 2

Once Azure has done it’s thing, go to the websites dashboard and find the URL which will be something like “”. Go there and WordPress will lead you through the installation steps of setting up an admin account. Once that’s finished, all that remains is to install your backup plugin of choice, upload your backup file and hit restore.

If all is well, after a little while (depending on how big your site is) you should see your blog, but hosted in azure at “”. All your links will redirect to your original domain, so be careful which site you’re on, but you can verify that everything has come back correctly.

Scrum Retrospective Experience – ESVP, Sailboat and Constellation

I recently conducted my first Sprint Retrospective since becoming a Certified ScrumMaster and although I think it went ok, I’m sure there’s room for improvement. I’m hoping that by writing about it I perform a more in-depth personal reflection than I normally would and if someone else finds it useful or can provide feedback, I’ll be very happy.

Brief Background

This is an established team that has great morale, but they’ve been through the ringer a bit. I was worried the enthusiasm for Agile was fading, or worse, we were just going through the motions.

Five Stage Retrospective

When I first joined, I asked twitter about the various retrospective techniques others liked and Ben Linders kindly responded. So when I saw the book he’d written on the very subject – – was cheap I bought it!

Unsurprisingly, I followed the 5 stage retrospective mentioned in that book and used the techniques within.

  1. Set the Stage
  2. Gather Data
  3. Generate Insights
  4. Decide what to do
  5. Close the retrospective

Stage 1 – Set the stage.

The aim/context of this Retrospective was two-fold:

  1. Understand the teams opinion of our sprint retrospectives
  2. Discover the biggest issue/worry that we currently have

We used ESVP Check-In to discover the first, which resulted in 4 E, 2 S, 2 SP, 1 ESV and 1 P. I’m reading that as I was partially correct in my fear that the team were beginning to lose faith in retrospectives, but it wasn’t as bad as I thought.

Stage 2 – Gather data.

To gather data from the team, I used the Sailboat Retrospective technique. I’m pleased to say it resulted in a lot of post-it notes, so the team were clearly engaged, but I’m worried/disappointed about the number of negative things that were noted.

Stage 3 – Generate insights.

The team talked through each post-it on the sailboat, discussing in-depth the reason for it being there. I used this time to try and see how strongly the team felt about the issue, if they all agreed and how big an issue it was.

Stage 4 – Decide what to do.

There were too many post-it notes to tackle at once, so I used the Constellation technique on a few I hand-picked and a few I asked the team to select as most important.

Not only did this get everyone back on their feet and engaged (there was a definite increase in discussion afterwards) but is a really clear indicator of the teams feeling.

We then took each one from most important to least important and came up with some actions to hopefully resolve the issues before the next retrospective in 2 weeks.

Stage 5 – Close the retrospective.

Nothing special to note beyond thanking the team for the patience and enthusiasm for a new approach. I also asked for feedback, which I’m hoping will come willingly over the next couple of days.

Personal Retrospective

In summary, I’m really happy with the retrospective. I certainly gained some insight and I think the team got something out of it.

What went well?

ESVP, Sailboat and Constellation proved very nice techniques.

What could I have done better?

I’m slightly worried I led the Generate Insights stage too much. I think the team lost interest a little and some of the momentum was lost.

What should I not do again?

In preparation for the retrospective I ran out of time to think about stage 4 onwards. I think that led to the loss of momentum.

Just Write Something

I’ve just renewed the hosting and domain for this place and in two years I’ve written 14 posts… including this one!

Clearly I’m not an active blogger, but during some reflection I’ve come to the conclusion that I’ve been putting off a lot stuff. What’s worse, when I do sit down I seem to get very little done as I’m over-thinking.

Turning Point?

Like anything nowadays, I turned to my friend google (other search engines are available) and came across this post from Scott Hanselman Analysis Paralysis: Over-thinking and Knowing Too Much to Just CODE which rung very true.

From the number of comments, I’m clearly not the only person and there seems to be various ways people (try to) overcome it. I particularly liked the Chistopher Svec’s comment of “I usually have these 2 xkcd comics close at hand to help remind me to Just Do It / YAGNI” referring to &

And if by coincidence, the first post on Christopher’s blog (at the time of writing has a title of:

“Doing nothing is cheap. Failure is cheaper.”

Sums it up nicely. Off to think about coding :)

70-486 – Useful Web API Tutorials

While studying for 70-486 I’ve found a couple of useful resources for studying Web API. Before listing each one, it’s worth pointing out that this is before the March 2014 refresh of the exams.

If you have little programming experience, I recommend you follow them in this order as they get more complicated as the list goes on. If however, you’re already comfortable with MVC and Entity Framework you can probably skip to the penultimate or even last option.

Microsoft Virtual Academy

The whole 70-486 Jump Start is definitely worth investing your time in. Obviously there’s no actual tutorial with this, but it’s a great starting point.

Build RESTful API’s with ASP.NET Web API

This is a nice and quick introduction to Web API that will not only get you up and running with Web API, but also a simple client to consume the service. Importantly, the code on the site works as is and is easy to follow.


  • Very easy to follow
  • Introduces Service Layer/Repository pattern
  • Shows how to capture JSON in IE! (I admit never knew this)
  • You build a simple client
  • Brief debugging in Visual Studio
  • Publish the example to Azure (I didn’t try this)


  • Download a 100+MB file for code snippets (which you don’t technically need)

Using Web API with Entity Framework

Although this is a 7 part tutorial of Web API with EF it’s not 7 times larger! It has the added bonus of introducing another part of the exam, Entity Framework, but nothing beyond the very basics. Again, you construct a client to consume the service, but this time with a little more detail.


  • Uses EF, so if you’re not familiar with that you get exposure and if you are, it’s a slightly more “realistic” tutorial
  • More involved Client UI
  • Uses Knockout.js (the MVC template I used has 2.2.0 installed so pay attention to version numbers)
  • Authentication, albeit the installed MVC template forms authentication (blink and you’ll miss the credentials)


  • 3 technologies (Web API, Knockout.js and Entity Framework) covered so a lot to pick up
  • starts slow, but gets quick quite rapidly, e.g. part 7 (hint: you can login as “Administrator” on the homepage)

Detailed Tutorial for Building ASP.Net Web API RESTful Service

As the name suggests, this is a more detailed tutorial of Web API than the other resources and although it’s well done, I wouldn’t recommend you start off with this one if you’re a beginner.


  • Covers Entity Framework, Dependency Injection and the Repository pattern so more “real-life”
  • Versioning
  • Full source code on Github


  • May have been me, but I think some bits have been missed as I had to refer to the code a couple of times to get things going
  • Doesn’t explain using Fiddler (and why should it, so make sure you’re happy with either Fiddler or some equivalent like F12)
  • Isn’t finished so no caching.


If you want a quick overview of Web API in preparation for 70-486, the above 4 resources should get you well on your way. I haven’t taken the exam yet, so who knows if it was worth the effort, but for those familiar with WCF, Web API appears to be very nice.