#noestimates is just story points done right

#noestimates is just story points done right

Estimation has long been a natural part of software development. Therefore, an approach like #noestimates, which gets rid of estimation can seem quite suspicious. After all, there are good reasons why we estimate. We need to know how long something will take, so that we can decide whether it’s worth doing or how much the customer should be paying. We also want to know whether we are on track to deliver by our deadline, so we need to know how…

Read More Read More

Don’t leave the sprint planning meeting without a plan

Don’t leave the sprint planning meeting without a plan

A sprint planning meeting has two purposes: Agreeing a sprint goal Creating a sprint backlog I have seen some teams where both these artefacts have been one and the same. The sprint goal is to complete a list of stories. The sprint backlog is that list of stories. This is certainly one way to do it but not a good one. I touched on what constitutes a good sprint goal in my previous blog post about preparing for the sprint…

Read More Read More

A successful sprint planning meeting is down to the preparation

A successful sprint planning meeting is down to the preparation

Have you ever been in a sprint planning meeting that sucked? I have. Admittedly, I have found myself running a few too! The worst sprint planning meetings I’ve experienced have all been down to a lack of preparation. In this blog post I will look at how the right amount of preparation makes sprint planning much less painful. Give the backlog sufficient attention before the sprint planning The product backlog needs a bit of tender love and care before the…

Read More Read More

Determining value using Cost of Delay

Determining value using Cost of Delay

This short blog post is the last one of three this week in which I explore methods for determining which features are valuable. In the previous parts, we covered the following: Value Poker – a technique for estimating the relative value between features Impact Mapping – a visual planning technique that helps us prioritise based on how each feature contributes to our objective Arguably, both these techniques are largely subjective. We make assumptions based on intuition, saying “this is more…

Read More Read More

Determining value using impact mapping

Determining value using impact mapping

This short blog post is the second of three this week where I describe methods for determining the value of features. In the previous part, we looked at Value Poker, a method for working out the relative value of features. In this part, we’ll be looking at impact mapping. What is impact mapping? Impact mapping is a visual method that helps us take a step back from the features and think about what we’re actually trying to achieve. Starting from the big…

Read More Read More

Determining value using value poker

Determining value using value poker

The product owner is responsible for making sure the product backlog is ordered in a way that maximises value. The goal is to enable the team to deliver as much value as possible, as early as possible. However, this can be easier said than done. How do we determine what is more valuable than something else? Often, we will be comparing apples and pears. What is more important: simplifying the checkout process or adding the possibility to subscribe to newsletters? This…

Read More Read More

Choosing the right metrics for continuous improvement

Choosing the right metrics for continuous improvement

I have come to a realisation lately that I’ve left a useful tool lying at the bottom of my agile toolbox without using it as much as I should. This tool is metrics. Sure, I’ve been measuring velocity and have been using it to forecast delivery. From time to time, I’ve also dug deep into Excel exports from Jira to support some of my observations (“On average, we need two sprints to complete every story”). What I haven’t been doing though…

Read More Read More

Why small Scrum teams rock

Why small Scrum teams rock

Why is it that the rules of Scrum limit team size to between 3 and 9 people? Surely, the more people on our team the better? More people get through more work? That is certainly true is some cases. For instance, if we need to phone 5,000 people to sell them loft insulation, more people manning the phones will get us there quicker. Unfortunately, software development doesn’t work like that. One often quoted study by Lawrence Putnam and Ware Myers…

Read More Read More

7 reasons some user stories aren’t useful stories

7 reasons some user stories aren’t useful stories

Simply writing a sentence on the format “As a x, I want to y, so that z” won’t make it a user story. There is a lot more to stories than this. In this article, I will take a look at what some common pitfalls are. 1. Stories that don’t deliver value on their own The goal of any agile process is to deliver working, demonstrable software frequently. The way we break down our work is incredibly important for our…

Read More Read More

We can only be agile if we keep things simple

We can only be agile if we keep things simple

Arguably, the most universally applicable of the principles behind the Agile Manifesto is the one about keeping things simple: Simplicity – the art of maximizing the amount of work not done – is essential. The first time I saw it, I had to read that statement twice. “Maximising the amount of work not done”? Surely, we’re in the business of trying to get as much done as quickly as possible? But no, thinking more about it, it does make a lot…

Read More Read More