Definition of Ready - "Ready for Sprint Planning" (Part 2)

Continuing on from my previous post on Definition of Ready- "Ready for Refinement" (Part 1) today we look at the next step in the Definition of Ready. 
In my opinion one of the most important events a scrum team attends is a Backlog Refinement session. The Backlog Refinement session is crucial in setting the team up for success. The purpose: vision, understanding and agreement. It's almost like building a user manual for a Lego set, you get an amazing picture on the box of what you are building (vision), the parts that we need to build (understanding), the steps to build it (agreement)? You then should have everything you need to follow the steps one by one, and slowly build piece by piece.  What does Ready for Sprint Planning mean?That is what Backlog Refinement should achieve and this will then contribute to what it means to be "Ready for Sprint Planning" to complete your Definition of Ready checklist. Ready for RefinementReady for Sprint Planning The term "…

Definition of Ready- "Ready for Refinement" (Part 1)

Over time scrum/agile teams go through many stages of development as mentioned in Tuckman's Model of Team Dynamics and it is important to if not done so already to establish your team "Definition of Ready" (DoR) and "Definition of Done" (DoD) to ensure that you are achieving maximum performance. If you have not yet established an agreed to workflow with your squad don't fear, see my previous post on Establishing your Agile Development Workflow for Ultimate Efficiency (Scrum/Kanban)

How to Run a 30 Minute Spotify Health Check for Your Squad

Today's focus is squad health, answering the question some may have "How do I check in on my squads and focus on improvement without taking up too much time?" 
There are two parts to answering this question, the first being "Check in on squads" and the second being "Focus on improvement"

Agile Estimation Cheat Sheet & Control Charts (Relative sizing techniques)

One of the main questions that I hear from new starters when first introducing them into the Sprint Refinement process of estimation is "I'm new and i'm not quite sure how this team estimates or what I should size this story?" There are some ways to speed up this process with your new starters and also provide some bumper rails to your team members. Control ChartAgile Estimation Cheat Sheet Now, like everything in the agile environment, there is not one correct way to do something. This is just one of the many methods that I have tried out. 
The Goal See completed stories, time spent in different transition statuses and how they relate to the original story point estimate to provide context for new starters and existing team members.
The disclaimer: Story points should not to be mapped directly to the amount of time it takes to complete. It is a rough guide based on a sequence of numbers and a gut feeling with all of the information present at the time of estimation, inc…

How To Be a Successful Distributed Agile Team

Distributed Agile teams are nothing new, teams have been working remotely for a long time even before what has recently happened in the world with people working remotely full time due to travel restrictions and lockdowns.

I've already heard a lot of people online saying, "Wow this remote working can actually work" and "It's so much better when we use video..."

That is exactly right, distributed agile teams are a thing! Can you believe it?!! However it needs to be done in the right way.

There are a number of studies that support Distributed Agile Teams and their success out there if you simply Google scholar search "Agile Distributed Teams" you will see a bunch of studies and articles.

One of my favourites that I have come across is the "Theory of One Team" by Siva Dorairaj which focuses on how teams that are co-located can be successful with teams working remotely around the world.

I don't usually get very theoretical, but taking b…

Establishing your Agile Development Workflow for Ultimate Efficiency (Scrum/Kanban)

Have you ever had a time when…
A user story kept going back and forth between “In Test” and “In Development”?A user story was “Ready for Product Owner Walkthrough” but did not meet the Product Owner's requirements?Your team were unclear of the Acceptance Criteria and Definition of Ready/Done?
Today I want to tackle how to manage expectations with your team and ensure the correct workflow is agreed and in place for your Scrum or Kanban process to avoid rework, risk and failure and most importantly is team contributed.
Team Activity: Establishing a new workflow from scratch: 1. Firstly you will need to start with a basic workflow, I'd recommend starting with a standard workflow such as "To do", "In Progress", "In Test", "Review" and "Done". Depending on which team or industry you are building for this can change dramatically, this can be due to external blockers or different definitions of done.

2. Get the squad together

3. Place …

RetroThemez: Making Your Retrospectives More Enjoyable

Retrospectives can be repetitive for well established agile teams, especially when you are in your 27th sprint (54 weeks). So it is important for the Scrum Master to come up with ideas to make these ceremonies which sometimes feel mundane and turn them into enjoyable sessions for the team to increase engagement and excitement.

This idea was given to me by a colleague of mine which allowed me to start thinking more creatively. In honour of me leaving the organisation she created a retrospective in theme of my new organisation. This was such an awesome spin on our existing retros I thought "why stop there?". So in collaboration with her we have started a collection of themed retrospectives for all teams to use and contribute to.

We call it "RetroThemez" and it can be found on github here. 

The flow of the retrospective follows the following structure:

Team shout outsWhat went well?What needs improvement?How can we mitigate risk? From…

Rainbow Sprint Planning, What are they? and Why should we do it?

So before I wrote this post I did a quick google search to figure out what people believe a"Rainbow Sprint" is and it is completely different to what I originally thought so lets change that shall we. What I coin a "Rainbow Sprint" is "a sprint that contains multiple epics or team objectives that have been agreed in sprint planning".

Why is this important you ask? Well I bring this topic up as it is very easy for agile scrum teams to be in 110% feature mode and not be able to provide value to other areas of the team's responsibilities.

For example the scrum team have been allocated multiple features to deliver into production, let's call them feature "Green" and feature "Red". Priorities based on value and capacity do not allow the team to also have some tech debt "Blue" to close out and not to mention are wanting to continuously work on their automation framework "Purple".

Rainbow sprints are another term f…

Agile delivery projection, transparency and an agile mindset

I recently had a question about how we track agile delivery in the team I currently work in. Let's all agree up front there is some rigidity to agile delivery and project work that we all do in the digital & technology space. Usually a project goes like so, there is a product vision, we agree the features we want to deliver for a first release (MVP) and then build on it iteratively from there. This creates a sense of scope, we then try to estimate a timeframe for this and from there we kick-off development.

In some of my previous posts I have explained details around Agile Estimation P1 and P2 which is up front estimations to gain an idea of release effort and time. However in this post we go into a bit more detail about real-time projection and transparency of teams.

The example I will use today is building a new front-end customer facing platform. This can take some time and the team have estimated up front potentially how long it might take them. Let's fast-forward to …

What makes an effective user story?

We've all heard the phrases INVEST and SPIDR (or maybe not, I didn't know about SPIDR until two weeks ago) but there are certain techniques that can make an effective user story. I don't want to focus too much on how to split user stories, but more so how I believe a well elaborated user story may look after working with various team members.

I have a set template (found here) that I tend to always use and seems to work well with my teams.

The scenario that we will talk through today will be a customer wanting to login to their portal using their mobile phone number.

House keeping tableWho are the various stakeholders?What is the reference number? (JIRA) This provides a context of who the collaborators of the story were/are and how we can navigate the land of JIRA. User StoryYour usual format of "As a...I want...So that..."Who is the user? (As a), What are we building? (I want)What is the value (So that)As a customer I want to provide my mobile number on the logi…

What does a valuable retrospective look like?

In my opinion a retrospective is one of the most valuable ceremonies that you can bring to a agile delivery team. The aim is to reflect on the last sprint usually two week cycle of agile delivery and provide feedback and find improvements.

Retrospectives are sometimes overlooked for their value that they provide to a team. Usually for the following reasons:

1. They are not run effectively and efficiently
2. Actions are not taken
3. Action are not actioned
4. Feedback is not captured

The usual method of a retrospective is to get the team to all provide feedback on:

What went well? What should we keep doing?What didn’t go well? What should we stop doing?What are you confused about?
One method that I usually use is the happy :) confused ? sad :( boards with post-it notes.

1. The scrum master will re-cap on some of the work in the last sprint along with any milestones or key meetings or showcases
2. The team will spend 10 – 15 minutes reflecting on this and write their reflections down on …

Agile estimation and how to... (part 2 of 2)

So we left off in the previous post on "How do we take estimates and turn them into a projected timeline?"

Now that you have identified the total scope of a project and the estimated story points it’s now time to identify how long it will take your team to achieve the goal.

We do this by using what is called velocity. This is a metric for work done, usually used for planning and measuring team performance.

Usually product owners (PO) would like to see a total view of a project so even the blue sky scenarios and not just Minimum viable product (MVP) can be used in your estimates and timelines.

There are a few methods to do this but recently I have been using the three round velocity estimation game and this is usually done with new teams. If you already have a well established team then you would apply your current average velocity.

To do this have your story map in front of you and as a team get your product owner to ask for the commitments of each developer for the first sp…

Agile estimation and how to... (part 1 of 2)

You would have seen my recent post on story mapping and bringing a project to life with UI, features and user stories. Now comes the fun part, estimates and how to use these in an agile process.

Understanding the size of a piece of work is always important to people, some more then others, especially when there is cost involved. The idea of estimates is to gain this understanding and provide guidelines to your stakeholders.

Some questions you are trying to answer here are:
"How long will this take us?""How much will this cost us?" One way that works for me is carrying out estimates for an MVP, which is a subset of user stories that are identified as a minimum delivery for added value.

Using the story map from an earlier post we use a tool called estimation poker.

How to play estimation poker
Prerequisites: Run through each story so the team understand the end-to-endBreak any stories down if something is to largeAgree on a Definition of Done - e.g. passed user testing …

The importance of story mapping

Ode to the story map...
This week i've been working through a number of features and doing a bit of a deeper dive into feature/story analysis of my current projects' minimum viable product (MVP) and how these can be placed onto a story map.
Story maps in my opinion provide a number of benefits to teams and other stakeholders in the business, such as: End to end visionAllow visual thinkingProvoking thought Gain an understanding of sizeContextualise customer journey and interaction Story mapping is a term coined by Jeff Patton an Agilist who has written a number of blog posts and books about all things agile (i'll post some references below).
Story maps have always been a must for me, they drive conversations in the early days of the project and provide a sense of vision for everyone to see openly. They are also a great tool to run in your inception (which I will get to eventually in this blog)
I like to run my story maps with visuals (User Interface), followed by features (…