CEC / CTC Part 1 Submitted

I feel that I need to be open and honest here. I messed up, but I am looking at it in a good way!

The plan has always been to work towards the Certified Team Coach and then follow this up with the Certified Enterprise Coach certification. I worked through the Part 1 form for CTC, had my pre-application call and was all set to kick off the journey. I looked at the CEC application on the Scrum Alliance survey monkey platform that they use to facilitate the application process for CTC and saw that I had a CEC application sitting there gathering dust, so I clicked the application more from curiosity than anything else. I saw that there was an option to apply for CTC and CEC together. I clicked it…

It took me back to a conversation that I had with a CEC a few years back where he told me that you could apply for both and you only need to answer one more question to get both together. I should know that Scrum Alliance change their processes and I should have checked this out.

Thankfully (I don’t know if this is a good thing or a bad thing) I have been working towards this journey for quite some time and in that time my role has evolved. It has evolved more towards the CEC competencies and I meet the pre-requisites for both certifications so I am excited to get cracking. I watched the webinar on CEC tonight and I am enthused by the process. I realize now that the journey that I have taken of working in a silo for a few years, procrastinating, rewording and rewriting my answers and then falling into that cycle again was not the way I should have done this. The progress I have made by working with CTC / CEC’s, other candidates and other coaches has given me more value than working on my own. The community seems really geared up to help people succeed so I will embrace this change in direction with open arms!

Thankfully both Part 1 applications are the same, so there has been no time lost and the answers I have for part 2 of the CTC will come in handy for the joint CEC / CTC.

Who doesn’t love a challenge…. eh.. ? haha!

I will update on progress and feedback once it comes through.

CTC Pre-application call

Last week was a good week! I finally made some progress with my CTC / CEC application by taking the plunge with the pre-application call. I am pleased to say it went very well. I thought I would document the outline here to help any candidates who are considering booking the call. in the near future

I reached out to Christine Thompson who is one of the reviewers for the CTC programme and arranged a time to meet up to review my application. The call lasted 1 hour in total. In all honesty, I should have done this a long time ago to help me progress towards the certification quicker by finding and covering off my gaps in experience. The CTC review team are there to help candidates meet the requirements before they apply which is a really good way to operate. When I applied for my CSP certifications it felt like you were dealing with a faceless organisation who would review and pass or fail as there was no feedback or human touch there. The ability to speak to someone, have an informal chat about my experience, my gaps and any questions I had around the process has moved me forward a great deal

The basis for the chat is to review the requirements that need to be met in order to obtain CTC. At a high level you need to have :

Coaching experience – Demonstrate more than 1,000 hours of coaching agile teams or roles, including multiple interacting teams and hands-on experience as part of a scrum team.

Education and mentorship – Have an active Certified Scrum Professional® certification and the ability to apply agile and Lean values, principles, and practices effectively.

Professional collaboration – Demonstrate a history of participation and involvement in at least five agile-related events and joining the Candidate-CTC Google group.

I have linked to the detailed requirements here and more importantly the expectations here.

I preferred the call over completing the part 1 application form. Being a more practical person rather than academic, I found it hard to complete the application and the amount of times have written and rewritten answers for part 1 has been scary. Getting nearly 20 years of experience down and into some of the very short word limits is very hard and I struggled to sell myself well, the call is totally different. The call gave me the opportunity to sell myself, describe the journey I have been on the get to this point and to ask Christine what the reviewer would be expecting in some of the sections I was struggling with to make sure I was on the right track which thankfully I was.

Well that is the basics, what did my call entail?

We covered everything here, so it is a good idea to print this out and tick things off ahead of the call.

The most important question was to establish whether I had a valid CSP certificate. I had renewerd my CSP-SM and CSP-PO in November 23 so was fully up to date. This is a deal breaker as if you don’t have a valid CSP certificate that you won’t be able to progress to application.

When it came to the more in depth questions, I cheated a little by progressing on ahead with the Part 1 write up. This was beneficial as questions around community participation, courses that you have attended to build your knowledge (instructor led) and informal knowledge building (books, courses etc) were covered. It is a good idea to sit down and really think about these areas and note everything down in the application to show the breadth and depth of your material and tick that box. I had the page open in front of me luckily which made it easy to rhyme off my learning and community participation but this could throw you if you need to think about it.

The organisation I work in at the moment really invests in the people who work there and I have experienced workshops, guest speakers and training courses that helped broaden my learning, you may be the same so make sure that you note these down, the learning doesn’t need to be certified or instructor led which is something to consider when filling the form out.

We covered my experience and evidence that I have over 1000 hours of Multi Team Coaching experience. The multi team coaching part is important to the CTC certification and you should keep this in mind for part 1 and Part 2 also. The second question I was asked was why I wanted to achieve my CTC. The key here is to be authentic to yourself and the way you describe what is driving you to achieve this milestone. If you are a fan of the scouts and collect badges and fancy a shiny new one, then this answer isn’t going to get you far unfortunately :D. I described the journey I have taken to get here, the mindset shift from where I was at the start of my journey and where I am now and how my thoughts on how I will use this to give back to the community have matured over the past few years. Some things to consider when forming your response too.

The item where I had a gap in was speaking. Scrum Alliance would like to see their CTC candidates out speaking in the community in the past 2 years. I have spoken at a couple of events in the past and it isn’t my strong point but I haven’t covered any speaking in the past 2 years. Thankfully I have something up my sleeve to help me meet this requirement so watch this space so this may be something that you need to consider going forward.

The surprise part of the application for a lot of people is the requirement to be able to have a coaching conversation to demonstrate coaching at the equivalent of ICF-ACC level. Thankfully I have been working towards ICF-ACC in the past year and was able to meet this requirement. Would I have been confident in doing this if I hadn’t been doing the ICF-ACC course, probably not, so it will be something that you will need to work on and practice, practice and practice some more. A good place to prepare for this would be the coaching outside the box blog where you can find some insightful articles to help you on your way or even better, reach out to the team if you would like information on the ICF training courses that they have.

The coaching conversation part of the pre-application can last from 10-30 minutes I have been told. Mine lasted 10 minutes and I was able to complete the coaching arc in that time which I was quite pleased with. I can’t emphasise enough here, find a partner and practice, practice practice if you haven’t gone down the ICF path yet. You don’t need to have the certification, just be in a position to demonstrate the competencies.

Overall I have been cleared to progress with my application and have part 1 ready to submit with a few tweaks off of the back of my call with Caroline. This felt like a weight off of my shoulders and I can’t thank Caroline enough for being an awesome host and giving some great pointers and things to ponder when filling out part 1 and part 2 in due course.

I hope this helps and good luck to those who are progressing down the same path 🙂

Giving back to the community

As part of the CTC / CEC process, one of the requirements is to actively support the Agile Community. This can be done through organising meetups, talking at an event or helping within the Scrum Alliance Community. Today I will focus on the work I have done with the Scrum Alliance Community.

It was suggested that a great way to help within the Scrum Alliance Community would be to help out at local organised events through Scrum Alliance or help out as part of the larger Global Scrum Gathering group. There doesn’t seem to be any Scrum Alliance groups in Scotland so my search had to go global. Maybe we should try and fix the Scotland scenario but that is for another day!

One activity that I really enjoyed was reviewing the abstracts for the Global Scrum Gatherings. I have worked as part of five review teams so far (Denver, Lisbon, Portland, Amsterdam and North Carolina) and it has been very rewarding. Scrum Alliance have gotten better at advertising this opportunity as time has progressed and have now started to advertise opportunities for reviewers via their Linkedin page. You will need to fill out an application form stating your experience and what not, but it isn’t too taxing.

So what is involved? You are added to a group slack page where people can ask questions, chat and network. You are then assigned into groups each with their own topic i.e. Scrum Mastery, Product Ownership, Coaching etc and you have your own Slack sub-channel to ask questions. You are then assigned up to 15 abstracts (outlines for workshops or talks) to review on behalf of Scrum Alliance. Each abstract will have 5 different reviewers from your group so that there is diversity in choice and relevance and I feel this makes it a lot fairer on the person who is doing the talk or workshop. A recent improvement was the removal of names of the person wanting approval so that no judgement could be cast.

The review is done in a separate tool which Scrum Alliance will sign you up to and give you access to. It is really easy to use and navigate and contains everything you need to review so it is a really smooth experience.

What did I learn? Lots. It is great to see so many highly motivated people each with their own viewpoint or take on Agility. It made me realise just how much time and effort is actually spent preparing, thinking, writing, performing and rewriting (inspect and adapt, so to speak) to actually bring one of these great talks or workshops into fruition. I admire the courage of the people who do it and are passionate about it, I will get there some day!

One cool opportunity I was given was to apply to be a part of the Amsterdam Gathering helper group where you could help out behind the scenes at the gathering but with work commitments, I couldn’t make it. This opportunity would have been great to help the community further and wouldn’t have been made available to me if I hadn’t applied to be a reviewer.

As a reward you will be given $100 off of the ticket price of the gathering, so win win!

Progress to CTC / CEC!

Well, what can I say, it has been a rollercoaster ride so far and unlike any certification I have taken in the past, this has been full on. It really makes me appreciate just how coveted the CTC is and hats off to the people who have already gained their certification as I know how much work is involved and how hard it is to achieve this. Unlike a one to three day course, this is a journey of self reflection and my comfort zone has definitely been pushed to the limit.

Having been a Scrum Master for nearly fifteen years before taking the big step into coaching I had taken pride in the fact that apart from my CSM in 2008, I had been relatively self taught with the help of some really knowledgable people and friends who I collaborated with through work to gain experience and boost my skill set. With coaching being a large part of the Scrum Master role and having made the transition to coach around five years with a lot of success in this new role, to hear that I needed proper coach training in order to obtain this certification was horrifying. This was the start of my mindset shift. One I didn’t realise that I needed.

I signed up for a path to CTC course with Lucia Baldelli and learned with some great people along the way. It gave me a great insight into what was expected of CTC’s and the application process and hearing the thought processes and experiences of others in my cohort was extremely valuable. Once I had completed the pathway it was pointed out that a Coaching Certification would be beneficial for the application process as there will be a coaching conversation in your introductory call with a reviewer. As I had been coaching for a few years at this point, I found it weird that you would need a Coaching Certification in order to get another Coaching Certification and I felt I was already good enough. Luckily Lucia knows when to be pointed and I took that as a hint that it would be beneficial for me so I signed up for her ICF-ACC course. I entered the process with an open mind and after the first session my mind was blown, this is what I was missing!

I realised that I had fallen into the consulting stance in a few of my engagements. People had looked to me as an “expert” and had come seeking answers and I knew that I had to lift myself out of that scenario as it wasn’t helping me or my clients or teams. The first few practice coaching sessions were uncomfortable as I switched from listening to answer to a deeper listening, listening to understand and process what the person was telling me to unlock what I can only describe as curiosity, questioning to get a deeper understanding to help unlock the clients thought process to usher them to solve their own problems. A world away from what I was used to.

Using the skills I had learned during the course really opened my mind to a new strand of coaching and it made things really interesting again although, whether my clients or teams who now experienced my new approach rather than be given the answers to their problems would agree, is another question! That was my mindset shift, I had been fairly fixed in my belief that I knew what what good coaching was but the professional coaching side really opened up another world and an improved toolset for working with individuals and teams and it came at the most opportune moment.

During this time my role in my day job changed. I moved to a massive Agile Transformation that was combining Scrum and Scaled Agile (SAFe). This gave me the opportunity to work with Senior Leaders in the transformation and also Leaders in the business too which put my newly learned skills to the test and has broadened my horizons to now look at the CEC certification too.

One area I didn’t want to overlook was community engagement and giving back to the community. I usually attend a lot of meet ups to learn from the community and have helped with small scale organisation at a couple of local meet ups and events but I knew that this would not be enough to meet the certification requirements. One opportunity arose to be part of the Global Scrum Gathering Denver review group where a group of Agilists come together to review the talks that people would like to present at the Global Gathering. It was a great experience, great to collaborate with some really knowledgable people and also get an insight into what makes a popular presentation. This has led to me volunteering for the Lisbon, Portland, Amsterdam and New Orleans Global Scrum Gatherings too, it has become quite addictive and a great way to give back to the community.

When I sat down to write this post I didn’t really think it would be this long! I feel pretty confident at the moment to sit my initial interview with one of the review members and will compose another blog post to let you know how that goes. I am looking forward to it. I hope this will be helpful for people hoping to sit the CTC / CEC going forward.

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. The most common way I have observed teams planning is where they 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.

You can find out more about the CTC process here