How To: Sizing and Estimation Game

The Zoo Game

When starting out with teams I like to facilitate an exercise called “The Zoo Game” to bring relative sizing and estimation to life.  It is a practical exercise that is run with the whole team together.

Getting started

If the team are located in the same office, then you will need the following equipment

Large post-it notes with XS, Small, Medium, Large, XL

Large Post-it notes with 0,0.5,1,2,3,5,8,13, 20 written on them.

Medium Post-it notes with the following animals written on them or use pictures of the animals for reference.

  • Flea
  • Bee
  • Mouse
  • Rabbit
  • Cat
  • Dog
  • Lion
  • Bear
  • Giraffe
  • Whale

A selection of stories from the team backlog of differing sizes.

If the team are distributed or working from home then follow the above instructions but use Miro or Mural to allow the team to interact.

Why we use this game

When teams start to work together they often equate points to either hours or days.  This can then become confusing for teams when something takes a few minutes and this can in turn lead to confusing scales which makes it hard for teams to estimate.  Jira has now allowed for decimal points in sizing which is adding fuel to the flames.  This exercise should help raise things up a little. 

With relative estimation, the unit that you use to compare items doesn’t really matter as long it is agreed with the team and the team are able to identify how big an item is in comparison to other items that are being estimated.  This will become apparent during the game.

We run through 2 sizing methods in this exercise to show the differing levels of granularity that each can bring.  T-Shirt Sizing and the Fibonacci sequence is used.

The outline

Place the Large T-Shirt sizes on to the wall, mix up the animals and place them on the wall nearby.

We kick off by explaining the outline of the exercise.  We are firstly looking to estimate the size of our group of animals relative to each other using T-Shirt Sizes.  Ask one person to kick the exercise off by picking the animal that they think sits in the middle value (Medium).  Ask each person to add one animal from the list to the scale reminding them that they can move items up or down but only if they discuss their thoughts with the team and gain agreement.

You should begin to see conversations or questions begin to emerge around what scale is being used.  Is it height? is it weight? Or even length has been used in one exercise.  As long as the team decide which scale they want to use during the exercise it should run smoothly.

Once the exercise is complete and the animals have been added to each of the sections ask the team for their observations.  They should see that each size acts like a “Bucket” where there can be a noticeable difference in size between animals.  i.e. the flea to the bee.  Point out that this is where we need to become a little more granular in sizing to improve our estimation. 

Move on to the Fibonacci sequence and perform the exercise using the same animals again.  The team can use the same agreed sizing scale.  As they move through the exercise they will see that using the Fibonacci sequence allows a more granular.

Once the animals have been populated, discuss the team’s observations and ask them if they could see themselves sizing in this way.  

Move on to populating their actual work items again, agreeing the scale while trying to avoid hours or days.

Using this in the real world

Once you have completed the animal sizing and populated the items from your backlog to the scale it is time to put this exercise to good use.

You can use the scale at your next refinement session to compare items in the backlog against items of the scale.  The scale is fluid, you may find that items move up or down as we begin to learn and unearth more detail.  After a few Sprints the team will begin to find enough muscle memory that they can move on from the scale and use it as a reference when needed.

How To: Backlog Refinement

The Scrum Guide states that, ” Product Backlog Items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog Refinement is the act of breaking down and further defining Product Backlog Items into smaller more precise items”

Although it is mentioned in the Scrum Guide, Backlog Refinement is an event that is often overlooked by teams or businesses who are just starting out. Time is spent reviewing Scrum training material with new teams and businesses and because Backlog Refinement doesn’t appear in any of the framework diagrams it is often glossed over leaving teams struggling to make sense of their backlogs. In past experience this was very common back in the day, it was the norm to have massive stories in the backlog that would just be too big to work on and if they were pulled in, they would carry over for Sprint after Sprint. Backlog refinement has made this less common as it has become more popular and people are now including it in their training materials.

As a team, we need to be confident that the stories we have in our backlog are prioritised and are refined to a sufficient size to allow us to complete them within one Sprint. The refinement session is the team’s chance to review the prioritised backlog along with the Product Owner. Reviewing the items within the backlog not only improves visibility and transparency but it helps the team break down the work into smaller chunks, reprioritise, ask questions, add detail and give initial estimates if possible. If there are any questions that cannot be answered the Product Owner must follow up and have these answered as quickly as possible to allow the team to refine at the next session.

Backlog Refinement sessions can be a regular occurrence for teams and it is solely the decision of the team what cadence they chose and what method they use to refine. Some teams may have the whole team present at refinement while some may opt for a 3 Amigo style refinement (Dev, QA, PO). Some teams may hold a session once per Sprint while some may have once per week. The important thing here is to choose what works for the team and regularly gain feedback on the effectiveness of the outputs and the cadence to make sure that they are effective.

What is the aim of backlog refinement?

The aim of backlog refinement is to take the prioritised stories that have not been subject to refinement and get an understanding of what is needed for the team to gain enough knowledge and understanding to complete these stories. We evaluate whether the requirements are clear enough for the team to be able to understand (The description) and how these will be signed off as complete (Acceptance Criteria). We also evaluate whether the story is small enough to be completed by the team within one Sprint. We will split the story down further if it is too large but still aim to keep the story valuable.

As we refine we may uncover new work. The team should then make the call on whether the new work is of a high enough priority that we should refine straight away and reprioritise the backlog or add the story to the backlog for a future refinement session.

We should leave the session with a prioritised backlog that will partly form the basis of our next Sprint. I say partly here because in my experience you can never tell when stories or bugs may slip into the prioritised backlog in the timescale between refinement and planning, this is normal and we need to cater for this. We should also leave with a list of actions that need to be followed up on before Sprint planning or next refinement. This can consist of a list of questions that may need answered, analytics data, etc.

What are the benefits?

I have found Backlog refinement sessions to be really useful in aligning teams towards their goals. Ultimately we are preparing our teams with enough knowledge and confidence that they can come into Sprint Planning safe in the knowledge that we have prepared and prioritised our backlog. There are no outstanding questions, dependencies have been called out and we can get to work straight away. There may be one or two stories that may have slipped in but these can be refined and added to the Sprint without much impact to the Planning Session. As we progress over time it should be as easy as pulling X amount of items from the Prioritised Backlog into our Sprint Planning session, having a conversation around how these help meet our goals, agree that these are the items that we should be working on and then crack on.

There is an old saying that I always relate to with Backlog refinement.. “Fail to prepare, prepare to fail”. In the early days we didn’t do refinement, we often failed as the stories were unclear and sometimes unrelated to our goal. Backlog Refinement brought us together as a unit giving ups the information that we needed to reach our goals as a team rather than individuals and our success rate increased.

Who Attends Backlog Refinement?

Depending on the method of refinement you choose you can either have the whole team present or select individuals as a 3 Amigos group. The Product Owner plays a vital role here though and it is paramount that they are present as they have the knowledge of the product vision, the roadmap and they are also the voice of the customer so are best placed to relay customer needs. They are required to be present to that they can answer any questions, offer any guidance and prioritise the backlog once items have been refined, new stories raised or stories have been removed.

The inner workings

When we enter stories into our backlog they do not need to be absolutely perfect. They are a placeholder for a conversation and the details will emerge as the team discuss and work out a plan of action for completing it. You can use the standard format for user stories below to help get the conversation started.

  • As an X I would like Y so that I can Z
  • Have a description (We need a rough outline of what the requirements are)
  • Have some Acceptance Criteria (Some criteria that you would use to measure if a story is complete or not)
  • Keep our INVEST requirements in mind

Idf what you want to achieve is hard to fit into a story we need to think a little differently. We should think of the goal that we are trying to achieve and what needs to be done to achieve this goal. This then allows the team to discuss the goal and the actions and find the best possible way to achieve this.

  • In order to complete X As a Y I need to do Z
    Have a description (We need a rough outline of what the requirements are)
  • Have some Acceptance Criteria (Some criteria that you would use to measure if a story is complete or not)
  • Keep our INVEST requirements in mind

The team will then work with the PO to discuss and evaluate the story. They can ask questions, suggest changes and estimate. If it is too big they can break it down into smaller parts taking care not to lose the value within the story. The team will then refine and estimate these smaller parts and reprioritise the backlog.

I hope this helps give some inspiration.

How To: Sprint Review

As always I have tried to break things down into PO / SM / Team responsibilities so that you know how closely these roles need to work together to get great outcomes.

Sprint Review.

The Sprint review is held at the end of the Sprint to “inspect the Increment and adapt the Product Backlog if needed”. In other words, it is the chance for the Team and the Stakeholders to come together and inspect what was **Done **in the past Sprint and gather feedback on the outputs.

It is an informal meeting where the team come together in what should be a comfortable setting to give a brief outline of the Project Vision, what the Sprint Goal was and how it related to the vision and what work has been Done by the team.

We can also give a brief overview of what work was forecast but not completed and any blockers that prevented us from completing the work that may require stakeholder intervention in order to unblock. Raising directly may increase the likely hood of a quick resolution, but we need to be sensible about it.

The Sprint Review is not only a great opportunity to showcase the work done by the team and build up morale but it is also an early chance to get tangible feedback on whether we are building the right thing or not, allowing us to pivot if needs be. Remember, fail fast, fail early.

Who attends Sprint Review?

The whole team attends Sprint Planning along with key stakeholders who have been identified by the Product Owner.

Ahead of the meeting (Some top tips for success)

* PO identifies stakeholders to be added to the review ahead of meeting and gives them to the SM

* SM refreshes update to reflect additions

* Team meet ahead of the review session to discuss what has been done and have a dry run

* PO agrees content with the team ahead of the review. There may be items (backend or such) that may not be of interest to our stakeholders

* PO calls for code freeze, no releases to be done ahead of review

* Team make sure all environments are accessible and what they would like to review is working (nothing worse than starting the review to find everything has been broken)

***What does Sprint Review Entail?***

* SM opens the meeting with the outline of the session (Remember that some stakeholders may be new to Agile)

* PO Gives a brief overview of the Product Vision and the Sprint Goal.

* PO Gives a brief overview of what has been done or can run through each piece of work individually

* PO Passes over to the Development Team to run through their completed work (Via screenshare if virtual) and answer any questions

* PO asks for stakeholder feedback

* PO will take note of feedback with the view of updating the Product Backlog

* PO will then discuss the rough vision for next Sprint (Based on output of refinement and feedback from the review)

* Team leave with a revised Product backlog and probable Sprint Backlog items for next Sprint.

How To: Sprint Retrospectives

Sprint Retrospectives are an important part of our inspect and adapt process. It helps our teams to continually improve by looking back at the last Sprint, identifying areas of improvement and creating an action plan to to implement improvements for the next Sprint.

The Format

The format of a retrospective can be as simple as “What went well?, What didn’t go well?, what could we improve next Sprint?. Personally I find that the simpler the format, the better as there can be less overhead for the team in terms of thinking time when formats change constantly.

Facilitators can also adapt the retrospective to incorporate Retrospective Games to try and make teams feel more at ease and build better team spirit if teams are working well. I have included links to give some ideas in this article.

Tips

* If the team have had a good Sprint with no major worries, don’t spend a lot of time over analyzing these points. It can have a detrimental impact on what could have been a great Sprint. Focus on the positives.

* If you, as a facilitator know that the Sprint has had a lot of ups and downs and has items that may need to be addressed, use a focused retrospective to address these points and air them with the team.

* Always spend a little time reviewing the action points from the last retrospective and update on progress. Being in a team that raises issues, plans to fix them and does not follow through can lead to a dip in motivation and cause retrospectives to stagnate. Follow up and celebrate successes as a team.

* Learn to read the team. Raising blockers or negatives within the team environment can lead to conflict or heated discussions. As facilitator, always be prepared for this and be quick to address and pick these points up with individuals outside of the retrospective.

* Create a continuous improvement board. Keep track of all of the changes that you have made as a team and review them to see how far you have come as a team.

Retrospective Material

Here are some websites with good Retrospective Games and formats to try with your teams.

Tasty Cupcakes: http://www.tastycupcakes.org

Fun Retrospectives: http://funretrospectives.com

Fun Retro http://www.funretro.io

What formats do you like to use with your teams?

How To: Sprint Planning

Sprint Planning is an event in Scrum where the team come together to align and determine which User Stories they will work on during their Sprint.

The Product Owner will come to the event with a Sprint Goal in mind that aligns to their product vision. The team will discuss the Sprint Goal, identify User Stories and map out their initial plan for completing those stories to deliver value to our customers.

Sprint Goals are negotiable and may change with team collaboration.

Who attends Sprint Planning?

The whole team attends Sprint Planning. The Product Owner plays a vital role in Planning as they have knowledge of the product vision, our roadmap and are the voice of the customer. They are required to be at the session to answer any questions, offer guidance and prioritize the Sprint backlog once items have been refined, new stories raised or stories have been removed.

What does Sprint Planning Entail?

We usually hold planning over 2-3 hours for our 2 week Sprints and teams usually experiment to find the optimal time for their team to complete planning without it being rushed.

A 4 week Sprint can usually take up to 8 hours to plan so use this as a guide when considering your Sprint planning timebox.

Good quality refinement can lead to Planning sessions being more organised and therefore quicker so it is always good to keep this in mind.

The team come together to discuss and agree on a Sprint Goal. The team the discuss the stories needed to achieve that Sprint Goal. The team will then use metrics such as Average Velocity or Capacity to agree how much work the team can realistically bring in to the Sprint. The session ends with agreement from the team that they are happy that the work that they have forecast to complete within the is achievable and that the team are ready to Sprint.

**Tips for great Sprint Planning**

* Refinement of stories has taken place before planning

* PO comes equipped with a Sprint Goal

* PO has prioritized the backlog based on Sprint Goal

* SM polls the team for capacity ahead of planning

* Look ahead to the Sprint Review. What will the team be able to review with stakeholders at the end of the Sprint?

I have seen Sprint planning done in a few different ways. There is the most common way that you will find in RBS where we come together in a 2-3 hour session to plan and get everything over and done with in one go or the method that I have used with teams below, that may help in this time of virtual meetings.

How could I make planning suitable for virtual meetings

***Ahead of meeting.***

* SM will poll the team for capacity ahead of planning.

* SM will update all stats and determine the teams average velocity.

* SM will meet with PO ahead of planning to confirm that backlog is prioritized.

* PO will review Sprint goal with SM.

* SM will review the retrospective actions to be considered for next Sprint.

***During the session.***

Sprint Planning 1 (The Scope) 1 hour long.

* Scrum Master explains the purpose of Planning

* Scrum Master will give a round up of the previous and Average Velocity.

* PO will give a run down of the Product Vision and Sprint Goal.

* PO presents a story and how it builds on our vision.

* SM will sense check with team and story added to Sprint if all happy.

* If the story needs broken down or is a new addition then the team will quickly refine.

* If there are any outstanding questions or missing requirements then the story should be parked and an action point raised to get clarity, it should not be included in the Sprint.

* The PO will collaborate with the team to prioritise the Sprint Backlog.

Sprint Planning 2 (The Plan) 1 hour long.

* The team meet to discuss the stories in detail and how they will be tested.

* The team then break their stories down into task level.

* The team sanity check the estimates given based on the effort given to the subtasks.

* Re-estimate items if needed

* Agree the scope with the PO and remove stories if the re-estimation brings above our average velocity or tolerance.

* Confidence check with team on Sprint Goal and Backlog items.

* Confidence check our team capacity (check ideal hours against committed hours)

* SM can start the Sprint

Path to CTC

I have been toying with the idea of sitting my Certified Team Coach for a while.  I had begun the process a few years back when it was known as the Certified Scrum Coach but with a new baby and a new job my priorities quickly changed.  Now the CTC seems to be the next logical step in my journey and I have been building up an array of great coaching techniques and tools over the past 2 years. It would be great to top off all of this hard work with the CTC certification to show for it.

There has been a lot of imposter syndrome at play with me, mostly down to being pretty new to an Agile Coaching role even though I keep telling myself that coaching has been a massive part of the ScrumMaster role that I carried out for well over a decade prior to me making the leap into Agile Coaching. There is always a doubt around whether my coaching style is correct, am I doing it right, etc. I have decided that the only way to find out is to give it a try and use the learnings to become a better coach, so I have decided to crack on with the application.

To help me along the way, I have joined the Scrum Alliance Path to CTC program which is a great resource of training videos to build your coaching knowledge and guide you towards the competencies of the CTC certification. In addition to this I have joined a UK CTC group where we come together to practice and learn together and build our skills in a friendly environment. My first visit was last night (9th September) and I found it really valuable, I feel that this will help build my confidence and maybe tackle the impostor syndrome. There are groups in the UK and US currently and these are free to join.

On first impressions the application seems a little full on and daunting, not like the other Scrum Alliance certifications that I have undertook. There is a pre-application call with a Scrum Alliance member to run through the application which covers topics including your career overview, what coaching approach you use, your coaching goals and your participation in the agile community. This will require some thought time and self reflection but I am looking forward to it.

There does seem to be an industry appearing around the application process with people offering paid for courses, paid for application reviews etc. I am going to try the traditional route of “DIY” and document my progress over a few blog posts and offer any tips along the way. It has been a hard slog to get to where I am at the moment and I would feel a better sense of achievement if I managed this without the need for a paid for service.

You can find out more about the CTC process here

Scrum from Hell revisited.

Today was a flashback kind of day.  I was part of a Scrum Master training day and one of the games the group played was “Scrum from Hell”.  It took me back to 2009 when I wrote one of my first Blog Posts about a game I played with one of my teams.  The blog post remains fresh with me as it is still one of the most viewed posts I have written as it still gets a lot of hits per month, even when my site hasn’t been updated as often as I would like.

Playing the game again was awesome and as I have gained more experience since I wrote the original post I looked on it from a different perspective.  Originally when I played the game I was trying to highlight to our team how disruptive one aspect of our teams behaviour was.  We had a few people in the team who loved to talk and would take the meeting off on tangents and no matter how many times the team brought it up at Retrospectives, the usual suspects still persisted.  We put them into the hot seat as Scrum Master and mimicked their behaviour.  They found it frustrating and could see things from the teams point of view and changed their ways.

Today, I saw the game as a great fun tool for highlighting how hard facilitation can be for a new Scrum Master to a new team.  In the beginning the daily standup can see people act in different ways when they come together as a group.  Some of these behaviours can be detrimental to the harmony of a team so it is a great way to highlight these bad behaviours to a team and give them experience of how hard it can be to not only facilitate a standup but any ceremony.

Instructions:

  • Split off into groups of 5 or 6.
  • Select 1 person in each team as Scrum Master and ask them to leave the room
  • Explain to the Scrum Masters that they will be running a Daily Standup.
    • Ask them to explain the format of the Daily Standup to the team.
    • Explain the 3 standard questions.
  • With the Scrum Masters still out of the room explain the rules of the game to the teams.
    • Ask the group to shout out some bad behaviours they have experienced in a meeting (Looking at mobile phones, arriving late, side conversations, talking over people were just a few we used).
  • Allow the Scrum Master to facilitate the meeting for 3-5 minutes.
    • When the Scrum Master starts the meeting the teams should act out the bad behaviour that they have chosen.
    • If the Scrum Master notices the behaviour they should call it out (promoting holding each other to account).
  • Ask the Scrum Masters to reflect on how they felt and what they learned whilst playing the game.

Feel free to check out my Original Post for more ideas on this game.

Big thanks to the team for refreshing me on this.

 

 

Distributed Scrum Teams

I was looking for inspiration for my next blog post when I found a notification telling me that I had an article sitting in my drafts section.  Distributed Scrum Teams was the title and it took me back to 4 years previous when this topic came into my head.  I was going to tell you about the successes that I had using distributed teams but I deleted all that.  As I began to edit the post I realised just how far we have come in just a few years and decided to highlight that instead.

When I started out in 2006 there was a lot of chatter about how distributed teams were not Scrum.  If you were using distributed teams, you were breaking the values of Scrum and that was bad.

“Scrum best practices indicate you should be physically near the rest of your team members, actually located in the same area of your work space. How can you effectively apply the tenets of Scrum when working with a distributed team, if you are breaking one of the key best practices? Or deal with the challenges of trying to detail a spec, but keep an agile and open development flow? or Communicate to a remote team the business priorities?” Jessica Johnson.

Fast forward to today and the landscape is so much different in 2018.  A massive change for me has been the way businesses work nowadays.  Businesses have moved with the times by introducing flexible working.  Some have decided to save in business rates by introducing rotas on when different teams can work within the office space to save them the cost of having to buy bigger offices.  This means that teams will be working from home more.  So your colocated team now becomes distributed to an extent.  It may not be possible for businesses to be fully colocated these days.

My previous company had distributed teams that had team members based across all of our UK offices.  Not only that, there were people working from home too.  We had daily standups via Skype where everyone had their camera turned on and one person shared the board to make it visible to everyone.  The team gave their updates just like they would in a physical standup and to facilitate any follow up conversations that occur from  the standup, we had a parking lot after the call where people would would stay to discuss anything that they felt needed discussed.  We used Skype for all of our ceremonies and tried to have the whole team together once a fortnight for planning.  This worked well for us.

I recently worked with a colocated team who were using a digital and physical representation of their Scrum Board.  The main physical wall worked as a big information radiator for the team and anyone else in the department who would take an interest.  The digital board was used to mirror our physical board.  This meant that people could work from home or Flexi time if needed.  The level of collaboration within this team was on par with the level of collaboration within my distributed team.  Each team had found the best way to work for them and improved upon this as they worked together.

In my personal experience it does not make much difference if a team are colocated or distributed these days.  The main barrier is the team themselves.  They must be committed and willing to collaborate with each other to make things work.  Maybe in the past the tools that we have to help us collaborate weren’t as powerful as they are today and I think this may be a huge factor in why it was considered bad practice to have a distributed team.  But now there are so many avenues open to teams to aid collaboration when they are not in the same office.  It is all inspecting and adapting along with your team and continually improving the way that you work together.  It will be hard to begin with but if it was easy, it would be boring 🙂

It was interesting writing this article.  It highlighted to me that not only is out teams constantly changing and improving but the business landscape too.  I wonder if all of those people who were complaining about distributed teams in the past are now embracing the change or even realise that this has happened.

 

Blogging and I.

I have been maintaining my blog for a while, quite loosely as you will see.  I often found myself having great ideas to post but when I sit down to actually write a blog post, they never seem to fit together well and ultimately they don’t get written.  I really need to practice what I preach and stop starting, start finishing!  I thought to myself.

It wasn’t until I started to listen to Geoff Watts audio book on Product Mastery  that I realised where I was going wrong.  When it comes to blogging, I needed to be more decisive (apparently my wife has been telling me this for years :D).

One sentence that stuck with me was “When things become difficult, it is tempting to put them off, to do a bit more research”.   Then another “The result, nothing of value is actually delivered”.  Both summed up my situation.

It really struck home today when I was sitting down to write a blog post on my first assignment as a contractor.  I had written all of the ideas that I had down on a piece of paper to get some structure before I would begin to type the post.  There were so many ideas in my head that I was getting nowhere fast.  I decided to clear my head and go for a run.

While out on the run I thought about the other things that I had to do today and suddenly it hit me.  I was subconsciously putting off the blog post as it had become too hard to write.  But why was the post so hard to write?  I went through all of the ideas I had and realised that I was trying to fit three blog posts into one and because it wasn’t fitting perfectly the perfectionist in me decided that the post wasn’t a good idea.  I realised that I have done this with so many blog posts in the past and it was something that I needed to fix.

I came back from the run and decided that I had to break the massive post down.  I decided to fact check the two quotes used by Geoff above when I found the tweet below, which summed up my predicament perfectly.

Tweet

This made me smile as I had already realised that the expectations for my blog post were unrealistic and decided to break the big post down into manageable chunks.  It then led me to write this blog post.  The outcome, I delivered value and have a couple of blog posts that actually make sense to me and will be easy to write.

It is amazing what taking a little time to clear your head can achieve.  I realised a lot about myself today in that when I get an idea for a blog post I try to cram as much into that idea as possible to a point where it becomes too big to actually do anything with.  I have a lot of knowledge, experiences and practices that I try to get across but have a tendency to overdo it which leads me to lose confidence and scrap that idea.  Being decisive about the content you want to appear in your post and not being scared to take things out that just don’t need to be there is key.

Hopefully this results in more blog posts from me in the future 🙂

Cheers Geoff 🙂

 

Sign up to save a life.

A bit of a different topic for my first blog post in a long while!

As I sit chilling out I am reminded of the significance of today’s date.

Exactly this time last month I was being wheeled up to a hospital ward having just donated bone marrow to potentially help save the life of a young child with Cancer. Everyone has it in them to save a life and hopefully after reading this you will consider signing up as it is such a worthwhile thing to do and can change the lives of so many.

Around 10 years previously my cousin Elaine was fighting her own battle with Cancer and it so happened that there was a drive by Anthony Nolan to find a match for a local child who was in need of a bone marrow or Stem Cell match.  After speaking with Elaine we decided (I say we as I like to think that I had some input in the matter :D) that I would go to the event and register as a donor.

Registering was really easy, a quick form to fill in along with a swab in the mouth and we were done. “You will probably never hear anything from us as a small minority are ever picked” I was told and off I went.

For 10 years this was the case until my phone and my wife’s phone got text messages at the same time along with 2 seperate emails.  The texts informed me that I was a potential match for someone on the Anthony Nolan register and if I would be prepared to donate. Things just got real!

With Elaine being very ill all those years ago I remember wishing there was something or someone who could help make her better but unfortunately that was not the case. I knew how the other family would be feeling and could relate to their position so there was little chance of me backing out from donating.  Having my own child too added more emphasis for me.  If it was possible, I would have donated that day.

Anthony Nolan were excellent in sending out all of the information regarding the operation and what was to be expected along with what would happen on the patients side. They organised everything from transport to accommodation for both my medical and my donation.

The medical that Anthony Nolan give prior to donation is very thorough.  It consists of blood checks, chest scan, ECG tests and general wellness checks.  Which I am glad to say I passed with flying colours which gave me great peace of mind, not only that I was OK but there were no risks to the recipient either.  After the all clear I was given a date for donation.

The donation date came around really quickly and I was soon off to London to the University of London Hospital.  I had never had an operation before so I was trying my best to think of anything but the operation.  Being scared of needles was playing on my mind but I really had to “man up” :D.  I had watched a YouTube video previously (I know … I know) as I was curious as to what the procedure was but even this didn’t put any fear into me so I knew that I was ready!    The staff at the hospital were all fantastic and helped out my mind at ease also.

In the morning I was taken down to theatre and put under general anaesthetic.  I remember waking up a short time later none the wiser as to what had happened.  It was like magic!

The medical team had taken over 1.5 litres of bone marrow from 2 areas in my lower back (pelvic bone) by the time I had woken up the bone marrow was already being whisked to its recipient to start the process of giving them a second chance.  It was an amazing feeling!

There is a lot of misconceptions about bone marrow donation in that people think it is very sore.  Actually.. you don’t feel a thing.  Yes, there is slight discomfort afterwards for a little while but in the grand scheme of things it is a little pain for a lot of gain.  I was up and walking around a couple of hours later that day.

You are potentially giving someone and their family and friends the chance of a lifetime and I for one feel privileged to be able to donate.  I also kept the promise to my Cousin that I would help someone if I could.

So today, I sit here fully recovered and thinking of the recipient, wishing them all the best and hoping that they are on the road to recovery.

You can register to donate at the following sites and they would be thrilled to have your help.   Things have progressed a lot since I registered and they can even post out kits to your home in order for you to register.  All it takes is a spit and you could save someone’s life.

There are people out there at the moment needing stem cell and bone marrow transplants, you never know, maybe you can give them the chance that they need.

16-30 year olds via @AnthonyNolan

18-55 year olds via @DKMS_uk