christianstivactas

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 Refinement Ready for Sprint Planning The term ...

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)

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"

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 Chart Agile 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...

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...

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 t...

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 . https://github.com/cs91/RetroThemez  The flow of the retrospective follows the following structure: Team shout outs What went well? What needs improvement? How can we ...

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...

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...

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 table Who 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 Story Your 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 prov...

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 thei...

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...

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-end Break any stories down if something is to large Agree on a Definition of Do...

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 vision Allow visual thinking Provoking thought  Gain an understanding of size Contextualise 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 I...