Why I Hate Story Points

Story points, everybody’s favorite scrum activity. I understand they are meant to be used to help size stories. What usually happens is they are used to determine a team’s velocity.

A sprint goal suddenly becomes lets get 20 story points done this sprint, not let’s deliver stories that have business value.

Also what happens to unknown work that ends up needing to be done, but wasn’t pointed? Well it still has to be done, but if you are judging a team on only story points, then they won’t get any credit for it. So maybe the team failed the sprint goal as they only got 10 points done, but in reality 10 stories only 2 of which had been pointed. Those 8 stories were totally unexpected work, we all know that happens from time to time.

So the standard system seems to be, backlog grooming in which planning poker happens, and stories all get sized by a guess.
A sprint is then planned on how many story points we can do. Where this falls apart is it is nearly impossible to guess how long a story will take from just reading some acceptance criteria.

So what’s my solution? Well in the past I have talked about specification by example as a means to split stories, but where does this fit in a Scrum world?

Well how about in your backlog grooming sessions, instead of just reading the acceptance criteria and voting, use examples.
By using examples here, we can usually see how big or small a story is, the idea being to get a story done in close to a week. So the rule of thumb is usually 4 or 5 examples per story.

Maybe you get a story that has 10 examples, well we can split it here. Now we have two stories in the backlog ready to go. If for some reason some managers still need story points, grand we can just make sure all stories are roughly the same size. If each story has roughly 4 examples then pick your favorite number, 3 for example. All stories are then 3 or smaller.

The idea being to focus on delivering the value of story and not wasting time trying to guess points. Adding up the amount of time spent guessing these numbers will show you how much time we are wasting on this exercise. It reminded me of this Dilbert cartoon.


Eventually your team will get really really good at sizing stories using examples and since all the stories are 3 points anyway, points will fall away.

In a previous blog I talked about the three amigos and discuss and distill. This is basically moving the discuss part of the 3 amigos into backlog grooming to help split stories. You can still keep the 3 amigos lanes on your board, as we can still use the examples as test cases, and here we can double check and make sure everyone understands everything before starting work.

OK you might ask me, well how do I measure my team’s velocity? Well you can measure the cycle time to done.

Say a new feature has 10 stories in it, and these ten stories have been groomed using specification by example. We can then say that each story should roughly take a week. Then the feature will be ready to go in roughly 10 weeks.

By getting better at our story sizing (which happens with practice) we can become predictable instead of trying to guess how long something will take.

Give it a go and let me know how you get on.


Agile Tour Dublin Notes

Firstly I must apologize for the lack of attention this blog has been getting recently. It has been a busy few months for me.
Secondly this post is yet again not going to be BDD part 3. I recently went to the Dublin agile tour, and have to share my notes. As always it was a brilliant day, with loads to be learnt, and a great after session which left me feeling a little sore the next day.

Agile Innovation – Colm O’hEocha (@ColmOhEocha)

Colm started the day by talking about how agile can lead to teams innovating. He said that every line of code we write represents cost, and the traditional development view is to do everything the same way every time. This may work for cakes, but we are not baking cakes, we are actually making recipes. So why would you make the same recipe over and over?
What we need to start doing is ship less code that delivers more value. So how do we do this? Well Colm suggests we change our way of working. Focus on maximising the value delivered not just on shipping code.
Innovation is about learning fast. So we need to create an environment where we are able to learn fast. Colm explained that waterfall is a bad environment to learn in, as we only learn at the end. Agile works well as it is all about learning. We try to figure out the problem via user stories and reviewing them. We create solutions to try and fix the problem. We use tools like the three amigos to create the best solution. Then finally we implement and deliver the problem fix. We do this in small increments and thus gaining fast feedback.

Knowledge is validated learning, so we need to try something to see if it is true. Fast feedback is so important as we need feedback to prove our ideas. If you want to learn a lot, do something that has a 50 percent chance of failing. We need to create a common goal for the team. Have everyone working on the same problem, not just ba first, dev in the middle and test at the end. We need to have rules set in place to show how we are going to work together, what is the team’s definition of done?
Innovation will happen when we learn by doing something, and then change what doesnt work. We need to create an environment of creative chaos, agile and scrum support these environments. You need something that challenges people, but doesn’t overwhelm them. For an innovative environment people should have more information than they need. To create a new idea, you need to have knowledge to combine. If you starve yourself from good information you are restricting yourself from innovation. Our teams need to have trust, the more trust the more we will share information.


The 7 Deadly Sins Of Scrum – Fran O’Hara (@OHaraFran)


Fran started out by saying Scrum is the dominant agile framework. So he would like to share with us 7 sins he has seen to help improve our agility.

Sin 1: Taking our eyes off culture.
Agile is about people, and people tend to resist change. So we need to embrace people. Don’t be tied to a plan, we need to embrace change and follow people. Don’t use contracts as a stick to beat people with. It is not simply, we do standups we are now agile. We need to get senior management buy in. Success is more much likely if we align with our stakeholders. If the people doing the work don’t buy into it, it won’t work. You will get a blame culture, the testers blame the devs, the devs blame the testers, etc. So we need to hire staff who enjoy working in an agile environment, does HR know this? Are they training staff, and looking for people with the correct skills?
It is all about people, remove fear and build trust. How you communicate change should take into account how it will affect people. You need to create a team culture. Encourage people to have a mix of roles, to be cross functional. The hardest part is getting people to work together.

Sin 2: Push versus Pull.
Only the team should pull the scope of the sprint. Not a PM or an SM, it’s the team’s job, the work should not be pushed on them. If you start to increase scope by pushing in work, you will cause problems. Technical debt will build up, people will start hiding work, quality will drop as people cut corners to get work done. Make sure to have a WIP limit, it’s a pull system like Kanban.

Sin 3: Planning Sins.
Our planning either daily or sprint, should only be done by the team. Sometimes daily planning just becomes a status report. It should be a self organising team planning the day’s work. Make sure the whole team is involved in sprint planning. It is not just planning, it is joint design so we need the whole team.
Our release planning needs to be light and adaptive. We need to have a test first approach. Don’t call it a plan, it’s not a set in stone commitment to deliver on X date, its an adaptive forecast. Try and figure out the biggest risks, focus on fixing them.

Sin 4: Product backlog refinement.
We need to make sure we have valuable items in our backlog. We need to have the whole team, otherwise we will need another meeting to explain everything to the team. We need to focus on story sizes. If the stories are too large we will end up with mini waterfalls.

Sin 5: Definition of done.
A lot of teams don’t have one, or have one and ignore it. It should be ever changing. We should use retros as a place to change it. Ask how are things really going?
The definitions can be too vague, tests are passing, but what does that really mean? What tests? Does everyone on the team know what tests, and what passing means? We need to have transparency and trust. Do all the teams have one? Does our organisation have a standard, if so make sure it is not too descriptive. We want teams to be able to adapt and change the definition of done to suit their own needs.

Sin 6: Sprint backlog.
We need early testing integration, this stops mini waterfalls. TDD is a big practice, early testing is good. We should have story level test practices. Test cases are only valuable if validated by the developer and business analyst. The devs can then write code to make those test cases pass. The worst thing is having test as a verify column, testing should be at the start and integrated.

Sin 7: Scrum master sins.
Scrum masters should be a team servant. They should not act like a team manager. Not focusing on teams culture is a big problem. Another problem is having a part time scrum master, this will damage a team. Also the scrum master needs to learn to use the power of a retro.

Testing In Devops – Vincent Pretre

Vincent started with a question. What is the best thing we can get from a devops world? Speed. We can minimise the total time through the loop, thus we get faster feedback. We need to make sure what we want to deliver will help our users.
Why do we want to change how we work? We want to challenge business assumptions, we want to make sure what we are delivering will have value.
We need to create an intimacy between our users and our teams.

Tools like BDD can be used to capture the software’s behavior. This creates a shared understanding of how the software works using examples. Everyone in the company should be able to understand these examples. Once the examples are automated they become a living document of how the software works.
But automation is expensive so do not fully rely on it. Use the testing pyramid, we should have more unit tests.
The next step is to write code to make all these tests pass, then to make the feature available. Roll out the feature once the implementation has been validated.

We want availabilty over pure correctness. We want the feature available for customers to play with.
We then iterate. Maybe the feature can be changed or removed? Back to step one we go, find the value of the feature.
What are the values to working in a testing driven devops world?
We get testing done up front, increasing the features value.
We can work incrementally and focus on the customer’s needs first.

We now have an environment which allows for experiments and new learning.

Our Move From Scrum To Kanban – Hugh O’Donoghue, Gordon McGuirk, Colum Kelly

What were the problems that made us want to change?
Scrum was just focused on keeping people busy. The delivery of work was very unpredictable. Tester were under serious pressure. Two weeks of work had to be tested in 2 days and the end of a sprint. We were doing loads of things, but nobody could tell if any of them were valuable. We had scrum processes in place, but none of the them were giving any value.

So what did we do to change this?

We created a plane to change things. We did a lot of training. We brought in outside coaching to get teams up to speed. To create a sustainable organisation we needed to make a deep change. Everybody had to understand what and why we were changing our process.

A big thing to watch, was trying to stop old bad habits from coming back. Make small incremental changes, don’t change everything at once.

The first change they made. Create a board, make sure all the work is visualised. They learnt they were doing A LOT of work at the same time, and A LOT of it was bug fixing. There was too much work being done at the same time, way too much context switching.

So they stopped that, they added a WIP limit to the board. By limiting the work in progress they increased their flow. Eventually they noticed that sprints feel away, as by doing less work they were getting more done.  

But some problems still showed up.

There was very little movement between lanes, devs did dev, qa did qa, there was little collaboration. So they created explicit lane policies, encouraging collaboration. Also they started gathering and using metrics, they became metrics driven. This allowed them to focus on different areas and use experiments to change things, using the metrics to see if the experiments worked.
Every team was different, so did not have to move at the same pace. That was a very important realisation.

Some other things that helped with move to Kanban. Playing games with the teams to highlight WIP limits and explain Kanban. They even hosted meetups including our own ministry of testing meetup (thanks again lads). This allowed the teams to share their discoveries with the outside world, and find out how other companies work.

Agile UX and Testing – Magda Targosz (@AgileMagda)

Magda started by saying that all we want to do is deliver a product to our customers. But not just any product, something that they want to use. What tends to happen though is as our product evolves the customers use changes. So what does the customer need?

Everyone might think they know the answer to that, but will have different answers. So Magda says we need to discover what our product is before we start building it.

So how do we do this? Well we need to work with our customers. Figure out their needs, and we can find out how to solve them. Magda suggests there are four key steps: Discovery, design, development and deployment. If we miss one of these steps, the other steps get more complicated and wrong. We need to ask who our customers are, create personas to capture how they think and use our product. Figure out what attracts them to your company, and what makes them tick.

Magda suggests bringing in the whole company and creating a goal, create a high level concept design. Start by answering the questions, found in the below picture.


Make everything visual, humans like to see before we create. Create a hypothesis and test it. Make wire frames, these are light weight as most will probably be thrown away, but will get us started.

Magda suggests using impact mapping and story boarding to bring the project ideas to life. Impact mapping and design phases become much easier as the team has been involved in all the previous steps.

Magda recapped by saying we need to learn who our customers are, find out what they want, and test our ideas BEFORE we start to develop them.

Make my team great again – Mary Walshe (@mary_walshe)

Mary started out by playing a small game with us to teach attribution theory. She should a picture of a badly parked car, said it was our car, and asked why did we park so badly?

Everyone wrote their answers on post it notes and they were collected. The majority of the answers were external problems. Something made me late, somebody else parked badly etc etc. Mary then showed a similar picture and asked, someone else has parked like this, why did they do it?

After the post its were collected, we had a new set of answers. These were all blaming the other person, the person is lazy or stupid. Mary explained we describe behavior in two ways, internally and externally. Internally is for us and our friends. They did bad as something was out of their control, they are good people, they did not mean it. Externally is for people we do not know, they are stupid, probably bad people, therefore they did bad as they are idiots.

So, how does this affect our teams? Well if we don’t know each other, we can tend to explain problems away externally. Those testers are idiots, those developers are idiots etc.

Marys answer is to get your teams collocated. We need to get everyone on the same page, if people are sitting together and working together, there is less of a chance to fall into us versus them.
Mary suggested making our lane policies explicit and making sure everyone on the team understands them, this will get everyone on the same page.

Everyone is coming to work to do a good job, so we need to make sure our team has an environment where they can collaborate, instead of blame.

After the talks I attended a KanBan pizza game. This allowed teams to learn the principles behind KanBan by making pizzas. Overall it was a fantastic day, I recommend everyone come along next year.