So you’ve just started out in Scrum, you are in your very first Sprint and you have a Product Backlog, nice going!
You’re going to come to a point where you need to turn your attention to the upcoming work in the Product Backlog.
Adding detail to upcoming stories so that they are ready for a future sprint is what we call Backlog Refinement.
This article will show you how you can start out refining your backlog. It’s just one way you can do it, as your team learns more, you will naturally adapt your refinement techniques.
As a Scrum Master who serves multiple teams, I often find it helpful to have metrics to generally see how each team are doing. Some kind of guide as to who I should spend more of my time with.
These metrics are also useful for the teams to understand how they can improve themselves — in fact this may even be more useful than my initial case for starting to gather the data!
The Agile manifesto states:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Any metrics we track should not…
How often do you sit down and discuss how things are going with the people you work with?
If you already work in a Scrum team, that’s likely the end of each Sprint. But if you’re not in that environment, it’s something to think about right? Think of all the problems you could solve if you just talked.
Sprint Retrospectives are a powerful force. They give you and your team an opportunity to inspect and adapt so that you can become better together over a long period of time.
A well facilitated Sprint Retrospective will give everyone in your team…
If you are completely new to Scrum, if you have never run a Sprint before and want to learn how to get started, I have a few tips here, a checklist of sorts, to help get you set up and running.
Scrum is build on the foundations of feedback, inspecting and adapting as you go.
These steps will help set you on that path.
If you haven’t read the Scrum Guide already, you really should read that first, you can find it here at https://www.scrum.org/resources/scrum-guide.
When you’ve read that, come back and we can continue.
Ideally 3–9 people.
Imagine this scenario.
You are a developer sitting at your desk, at home, connecting to your regular Sprint Planning meeting on a Monday afternoon. Another Zoom meeting filling up your day.
People are joining a bit late after another slightly extended lunch.
You just want to get this over with.
You just want to get this meeting out of the way so that you can get back to building something again.
Why are you you in so many meetings these days anyway? What happened?
The Product Owner gets things started.
We’ve carried over a few stories again, so we re-estimate…
Over the last month or so, I’ve been considering whether the workflow dictated by my team’s Scrum board is indeed a mini-waterfall within the Scrum framework.
In this article we look at how you can simplify your workflow and unleash the power of sub-tasks to supercharge your team performance.
Here’s what my teams Scrum board currently looks like:
The purpose of Sprint Review is to get feedback on the Increment of functionality you’ve built each sprint. This feedback goes directly into the product backlog, ready for the start of your next sprint.
Sprint Review brings to life the 3 pillars of Scrum; Inspect (the Increment), Adapt (your plans) and Transparency (showing what worked and what didn’t).
In this article, I’ll show you how you can structure your Sprint Review to help achieve the feedback you need to succeed.
I’d like to introduce you to the purpose of Agile Batman. The reason I write, what you can expect to see in my future stories and how I can help you improve and be a better Scrum Master.
This is not about training, it’s about everyday, real-life examples of what I experience as a Scrum Master. I don’t know what’s going to happen next — but I will take you on that journey with me.
I believe that there are people out there who could benefit from a helping hand, to improve their day to day working lives. …
If you’re completely new to using story points in Scrum, then this worked example of using story points, and team velocity in sprints should help you understand how they can be useful.
Before we get started, a quick refresher on what story points are:
story points are a measure of complexity, effort, and doubt (uncertainty/risk).
If you’re completely new to this, have a read of this first.
Imagine you are part of a team of painters working for a fictional company called “Paint by Points Ltd”.
Learn how to get started estimating with story points and why you shouldn’t use time-based estimates.
If you are just starting out with Scrum, you are probably used to estimating in units of time (hours, days, weeks, months, years etc…). This is fine to start with, but estimating using units of time comes with a few problems:
I’m an energetic and enthusiastic Scrum master who loves music, cars, computers and helping other people succeed!