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.

Netflix – Less Is More

I know, I know I said I’d write part 3 of the BDD post. I promise I’ll get to it.

But recently I started watching a new Netflix show that got me thinking. It’s called Castlevania. It completely appeals to the Dungeons and Dragons playing geek in me, everyone should watch it.

But what I thought was interesting was how the show aired. I was told about this show by my friend, he was complaining that as he was just getting into it, IT ENDED.

Netflix has trained us to binge our TV, we can’t wait week to week anymore. They drop whole seasons at once, they even autoplay the next episode. That’s what I thought was interesting about Castlevania. They only made 4 episodes.

Now recently Netflix has been cancelling some of their shows. So I thought that maybe only releasing 4 episodes of this was a kind of taster. I found a cool quote from the CEO of Netflix Reed Hastings on cancelling shows. He said, “I’m always pushing the content team. We have to take more risk. You have to try more crazy things. Because we should have a higher cancel rate overall.” This is amazing lean thinking, keep trying new things, fail often and learn from it.

After watching the show, I totally agreed with my friend. So I took to facebook to see what everyone else is thinking. I found this:

Pasted image at 2017_07_25 02_51 PM (1)

Loads of people demanding more of the show. Don’t believe me, give it a google. Check out the reddit page, or the rotten tomatoes reviews. Now I am not claiming to understand why there was only 4 episodes. I know that kind of animation is hard to produce and takes a lot of time. But after reading the CEO’s comments, I would like to think this is a minimum viable product of sorts. Get your users addicted to binge watching TV, then only release a few episodes. Then just wait for feedback. If nobody replies, you have only wasted the time it takes to make 4 episodes. But if people demand more, well you can start working on more.

It looks like it worked. As you can see if the screenshot above Netflix are making 8 more episodes. So what can we learn from this?

Fast feedback is the key. Are we building a big feature currently? Does it really need everything? Would it make more sense to have something simple that just shows the basic idea? It doesn’t need to look pretty (my designer friends will hate me for that). Once it shows off something new, it can be used for feedback. All the rest can be done with the customer who is interested. Maybe the cool new feature you are building is actually not going to sell, it would be great to find that out early.

Let me know what you think.

Where To Start Part 2

This is the second part of my original where to start with BDD post, which can be found here: https://thoughtsontest.wordpress.com/2017/03/22/where-to-start/

Alright so now our team is a bit more collaborative. We have a multifunctional team, with some developers, a tester and a BA. We are also visualizing our work, and limiting it so there is work being finished and not just started. Now we are in a position to introduce BDD.

So at this point we should have some form of KanBan board. Work starts in the “To Do” lane and continues to the “In Progress” lane. Something interesting to think about, are there many bugs being found in the testing lane? In the last post I talked about developers not picking up new work until all the bugs found in the testing lane are fixed. But how can we try to prevent those bugs in the first place?


This is where BDD fits in nicely. For those that don’t know, it stands for behaviour driven development. I have previously talked about what it is and why I love it. It allows for a conversation before any code is written. Personally I have found most bugs come from missing or misunderstood requirements. So if we can agree on acceptance criteria together then there will be less confusion in requirements and less bugs.

The easiest way to start is by adding a new lane to your board. After “To Do” and before “In Progress” add “Discuss”. So what happens in this new lane? The answer is simply a conversation. This is where the 3 amigos fit in. A tester, a business analyst and the developer who has just picked up the story. The most important aspect of BDD is this conversation. We can now talk about the requirements, and the expected behaviour of the software. This conversation should remove confusion in what the value of the story is.

This is easier if we just start with a user story and no acceptance criteria. The AC will be written as a group. Each person will bring their own unique viewpoint, if there is already acceptance criteria then confirmation bias can make us miss something. As it is easier to just not think and accept was is already written down.

What I have found works is specification by example. So start by trying to capture the behaviour using examples. John Ferguson Smart recently ran a workshop in which he talked about example mapping. I loved it and his ideas can be found here: https://johnfergusonsmart.com/feature-mapping-a-simpler-path-from-stories-to-executable-acceptance-criteria/

Using examples can also be a great judge of story size. Usually if there are more than 4 examples I recommend splitting the story. Keeping stories nice and small reduces complexity and helps get fast feedback as they take less time to get to the customer.

BOOM we now have examples. Now its time to add a new lane, call it “Distil”. This is where we turn our examples into automatable acceptance criteria. The examples become “Given, When, Then” steps. These can then be automated as failing tests. The story can then progress into the development lane and can be started on.

To make this a little more clear, in my next post, I am going to go through a practice story.

So like Led Zeppelin famously sung we don’t want any “communication breakdown” driving us insane. Give this a try and let me know how you get on.


Test Bash Belfast – Afternoon Session


One thing I enjoyed was that lunch was provided. This means nobody had to leave and we got to meet and talk to fellow test-bashers. My favourite part of any conference or meetup is meeting folks. You can learn from talking to fellow testers just as much if not more than from some talks.

On to the afternoons talks.

Shift Left, Shift Right, And Improve The Centre – Augusto Evangelisti (@augeva)

Gus started off by saying it was ok to sleep during his talk as he had the after lunch death slot. Of course Gus is way to energetic for anyone to fall asleep.
He started out by busting some myths about continuous delivery (CD). Such as:

  • CD does not work for complex things
  • CD teams have buggy software
  • CD can only work in non regulated industries

Gus went on to mention various companies such as Facebook who proved these wrong. We tend to complain that our software is too complicated for this to work with, but we would be lying if we said we are more complex than Facebook.

A team should be able to envision, analyze, monitor, and support software. Teams can do this, in three main brackets, left, right and the centre.

Shift Left:
Reduce the complexity of the code. Chunks of code should be small, Gus said about the size of your head. This makes it easier to review and maintain.
Using BDD as a collaboration tool will help keep work focused and uncomplex. This leads nicely into test automation. Pair programming can help reduce complexity and ties in well with code reviews. Another cool idea was mob programming. Maybe trying it for one or two stories and seeing how it works. Of course impact mapping is also a brilliant way to question the value of features, before any code is written. Gus then mentioned improving testability but thanks to Rob from the morning did not have to delve into the subject. Another good shift left activity mentioned was WIP limits, this allows a team to focus on tasks and actually start getting work finished not just started.

Improve The Centre:
The centre is usually where we live as testers. We are used to exploratory testing and getting bugs found and fixed. But Gus says to help improve here, we can teach others. We can pair up with our team mates and teach exploratory testing. We can help everyone to get thinking like a tester, and at the same time improve our own dev and analysis skills. Pair exploratory testing is a great way to do this. Even showing some testing in the demo can help explain how we think, and help share ideas.

Shift Right:
Right shifting is all about finding the value in what we do. This is where we engage the customer. Gus suggests monitoring the customers use of our software. We can then see what is used and what doesn’t work. This allows us to use customer feedback to design new products. A great way of doing this, is by using canary releases. For those who don’t know what this is, here is Martin Fowler’s explanation: Canary release is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody.

As testers how can we help do this? Gus answered by saying we need to develop three core skills. These are:

  • Active listening
  • Empathy
  • Influencing

A Test Pyramid Heresy – John Ferguson Smart (@wakaleo)

John says that test automation is like any other tool. It is either a benefit or a hazard. So we need to ask ourselves, how much are our tests worth? Three questions we can use to figure that out are, why, what and how.

  • Why are we doing this?
  • What are we trying to test?
  • How are we going to test it?

Without asking these question the testing pyramid can very easily turn into the testing ice cream cone. Don’t use a web test when a service or unit test could do the same job. My favourite point John made was about writing unit tests. Writing unit tests after the code is written is largely a waste of time. Unit tests that are written after the code, will perfectly test that the code is doing the wrong thing. If we write the unit tests first we can guide how the code is written.

Tests come from different sources. There are three main areas:
Business tests – Typically acceptance criteria and created using BDD (feature mapping/example mapping).
QA tests – Usually exploratory and found manually.
Developer tests – These are usually unit and integration level tests.

Instead of focusing on writing loads of tests, start by writing examples of how the API should work. Tests should have three main roles:

  1. Discovery – Using tools like impact mapping to help figure out what features are valuable.
  2. Describe – BDD tools to help describe and document the software.
  3. Demonstrate – Tests should show the code does what you expected it to do.

Testing In Production – Jon-Hare Winton (@jonhw87)

My first thought when I heard this title was, this man is insane. Testing on production is pure madness. But I decided to put my bias aside and see if there was some method to the madness.

Jon started by saying we do most of our work very far away from where our users are. Test environments are not an accurate portrayal of live. OK he has a point here. Jon then says what’s wrong with our test environments. We test something, make a mess, don’t clean it up and move on. This leaves us with a really messy area to test. They are lower in importance to our dev environments so don’t get the same level of maintenance. They are inaccurate and full of weird test data. Are they really a good environment to use the software the same way as our customers?

Feature toggling was Jon’s recommendation. What has worked for them is toggle something off to the customer, but start testing on live. Jon was saying they started slowly, just manual testing, just a little bit. Eventually the automation was run on hidden live environments. So once the feature is tested on live it can then be toggled on and the customer gets to see and use it.

I was sold on the idea. I now want to try it. Testing on production, maybe not such an insane idea after all.

The End

This is where my notes ended. My head was about to explode with all the information I had taken in over the day. I decided to just listen for the last two talks. So I must apologise to Sharon McGee, and Simon Tomes (@simon_tomes ), for not having any notes.

Luckily though it has taken me so long to get this second post out, the talks have since been put online. I highly recommend everyone get over to the dojo and watch the talks, especially the last two, they were fantastic.
They can be found here: https://dojo.ministryoftesting.com/series/testbash-belfast-2017.

You can also look out for me messing up a 99 second talk, by not being able to make a solid point in 99 seconds (shocking I know).

Roll on Test Bash Dublin, watch this space for more details.

Test Bash Belfast – Morning Session


I am just back from the Ministry of Testing’s “Test Bash” in Belfast. First I want to say how fantastic it was, I really enjoyed the day.

Here are my notes from the day. These are just some points I jotted down, not everything from the day, so if anyone thinks I missed something cool, please share it with me. 

Cynefin For Testers – Liz Keogh (@lunivore):

Liz opened the day with a talk about different levels of work complexity. Liz says we estimate work into 5 different areas of complexity.

5. Nobody has ever done this.
4. Somebody outside the organisation has done it, but we are not sure if we can do it.
3. Somebody inside the organisation has done it before.
2. Someone in our team has done it before.
1. We all know how to do it.

We insist on doing the 1s and 2s first as we like things we know how to do. What we should be doing is the 5s and 4s, failing and learning from them. So don’t insist on doing work we already know how to do.
Another great point was humans LOVE seeing patterns even if they are not there.
An example Liz used was this:
1  2    4  5
What is missing from the above list?
Well following the pattern we get, 1  2  3  4  5. But if we tried to break the pattern or ask for some context we may get something else like, 1  2  :  4  5.
My main takeaway from this talk was to work on the more complex things first, fail and learn. Also try and break pattern matching even though as humans we love patterns.

Tested By Monkeys – Jeremias Rößler (@roesslerj)

I learnt a new term from this talk and loved it, banana software. When you buy a banana it is usually green and ripens when you take it home. The same can be said with software, when it is released it is unripe and ripens when our customers start finding bugs. Which leads on to another great point, when is a bug a bug?
Jeremias answered with “when it is not a feature”.  Which is a brilliant point. He went on to say, if your customer is used to your software already you can’t change it. This means that even if we find a bug, it may be being used as a feature by a customer, if we “fix” it we may be breaking our software for a customer.
So regression testing is NOT trying to find new bugs, but checking that the software works they way it is currently working. So even if the software is wrong, it should be the same wrong every time.
This is where we use the monkey. The monkey can do the boring regression checking for us, and leave us to do more fun things, like exploratory testing or questioning business value.
What I took from this talk was that we should be automating the boring checks and just because we think something is a bug our customers may not. This talk will be given at Agile Testing Days, if you are lucky enough to be heading to it, I highly recommend checking it out. 

The Automated Acceptance Testing Paradox – Mark Winteringham (@2bittester)

Mark asked a valuable question – how do we know what is and is not acceptable in our acceptance tests?
Webdriver is a powerful tool but cannot test UI design. For example if a website loaded with no CSS or JavaScript the acceptance tests will still pass. So what do our acceptance tests mean to us as a team?
We should not use our tests for validating, but for guiding. A wonderful quote from Mark, “a failed check is an invitation to explore”.
So if the check fails have discussions, explore the area. Is the check failing for a correct reason? Is it even valid anymore?
What if a developer is working on an area of the code, and the tests are still passing? Usually we celebrate this – fantastic we have not broken anything – but what if the checks are not correct and thus of no value? Maybe we have made a wrong assumption, we can use this checks as a guide to ask these questions. 
Tools do not replace us, they support us.
My main takeaways, be aware of your assumptions. User acceptance checks are guides, and other testing activities are required.

A Tale Of Testability – Rob Meaney (@RobMeaney )

Robs message was clear, lets see what can happen if we design software with testability in mind. What our your current testing problems? Bring them to your team, fix them together.
Some questions to keep in mind, how can we make this software easier to test? How can we design it to be easier to test?
Look at everything, boundaries, all our internal dependencies, hardware, etc.
Get into exploratory testing, learn, design, execute and get feedback.
To me Rob’s key points where collaboration and removing the poor bored zombie tester. Involve him in your design and prevent problems.

Testing So You Can Move On – Nicola Owens (@NicolaO55)

I am not a consultant, so I think some of the advice in this talk whilst good was lost on me. Nicola focused on getting a company into a comfortable place with their testing so you can leave and have helped.
Some points I did take from this was around communication skills. Asking the right questions to leave somewhere with good testing practices.
What will make your life easier when I am gone?
Would you like help with that?
Try to earn the trust of folks who don’t usually like test.
Great points to think about.

This takes us up to lunch. I am aware that there is a lot to digest here. So I will leave after lunch to another post.

Where To Start

Recently at a ministry of testing meetup I got asked an interesting question. The question was: “How do I start BDD?”

To me this is interesting as it depends on what level your teams are currently at. Visualization is the key to start any kind of agility. So what I would suggest is start there.

What happens to the work? Is there a backlog of cards sitting in some online tracking tool? If so thats a great place to start. Get a big whiteboard and stick it beside the team. Add some columns that represent the work a team does with a user story. We can start simple, the board will probably ready something like: Next, Develop, Test, Ready for Production, Done.


Having the board beside the team will really help show blockers that can get lost in online tools. This allows the team to run a morning standup focusing on the stories as they move through the board. In the standup start with the closest story to done and work through the board. This hammers home the importance of getting work finished instead of starting new work.

After this I think you may see a lot of work in progress (WIP). There will probably be work queuing up in test, and developers working on multiple stories. So this is where we introduce a WIP limit. The Kanban idea of “stop starting start finishing” works really well, and a WIP limit is where you will notice this. The idea behind WIP limits is to encourage team work instead of work being passed off to different people. A good place to start is having a WIP limit set to the number of developers. If there are 4 devs on the team then start with a WIP limit of 4. This means that no other stories can be worked on until the 4 are done. This encourages pairing amongst team members, as the dev is no longer handing over work to a tester, they can work together to test something. This stops a queue of work forming in test, and helps eliminate blockers.

At this point you may be thinking you are not using all the capacity in the team. When a tester is working on a story surely a developer can be working on a new one? Well this leads me to ask what happens when a bug is found in test? Another story is spun up and now the developer has three cards to worry about. This means some fire fighting starts to happen or low priority bugs are deemed not important enough, and we end up going live with bugs.

It may seem counter productive, but less is more. If the developer is only allowed to work on one story at a time then bugs raised will be addressed straight away. It also means we no longer need a bug tracking tool, I have used red sticky notes on the story to show a bug.

So now as a team we can focus on getting stories done instead of starting new work and never getting anything fully finished. Have we done anything too stressful? Not really just visualizing our work and limiting our work in progress. There is probably enough here to start with. I am also aware I never answered the original how to start BDD question. But this is really laying the foundations. In my next blog I will show how easy it is to add BDD on top of what we have done here.

Paul Mccartney understood the value of working as a team in his frog song, “Win or lose, sink or swim….We all stand together”


P.S. This all came from a conversation at Ministry of Testing Dublins last meetup. I highly encourage everyone to check out @ministryoftest and find a meetup in your area.
For all the latest Dublin meetups check here:

On Safe Ground

I recently watched the David Bowie documentary “Five Years”. The documentary focused on five key years in his life and showed how he kept changing his sound and style. It was told through interviews with people whom he worked with it and featured tonnes of his quotes. I have quoted and used Bowie before in this blog, but something he once said really hit home with me. The quote was used to describe why he kept changing, he said : “the minute you know you’re on safe ground, you are dead”.

This seems a little bit intense, but what about Bowie wasnt? It made me think about feeling safe and getting comfortable in a working environment. Now there is nothing wrong with being comfortable in what you do, it means you are good at it. It has happened to me in the past, but once I start feeling safe I can get lazy. Also just because something is working, does not mean it can’t be improved. Taking Bowie as an example he could have easily just coasted, but no, right up until he died he was experimenting and trying new ideas.

So what can testers do to keep their days interesting?

Become T-shaped is the answer. For those of you who have not yet come across the term the following is my understanding of what I strive to be as a tester.


tshapedWhat does being t-shaped involve? Well if you take a quick look at the picture, you will see a person with a core skill and two arms worth of others. Your core skill is whatever you enjoy doing the most, developing, testing, or analysing business requirements. The t-shaped part comes from the arms. Having an arm for each other skill makes you a more well rounded team member.

As a tester if I have some understanding of development it makes testing easier but also more interesting. This is also true of having a business understanding. No matter what your role is on the team, it is GREAT to know what you are doing is delivering customer value. It also really helps if you understand the customer’s needs, this allows you to think like the person using the software. For a tester this makes our jobs easier as we will know how the software is going to be used. This knowledge will make a developer’s life easier as well. There are usually a million different ways to create something, knowing its use up front allows us to pick the fastest, smartest way to get a working solution.

Give it a try, you will probably find your teammates will be happy that someone is helping them with their workload. You may also find it makes your day to day work more interesting and you will no longer be coasting on safe ground.

I will leave you with a quote from Soundgarden’s Chris Cornell, “Arms held out, in your Jesus Christ pose”.

What Chris did not realise is that he was talking about being t-shaped.


Just Keep Failing

Over the holidays I started reading Bruce Springsteen’s autobiography. It’s a very honest and interesting read, I highly recommend it. Any fans of the boss know he is sitting on a mountain of unreleased material, the book explains why. Once he was given his album budget and recording time, he would just go straight to the studio with the band and record songs until they ran out of money. He put it this way; “We kept on, exhausting ourselves in the process, but exhaustion has always been my friend and I don’t mind going there. Near the bottom of its fathomless pit I usually find results. We failed until we didn’t.”


Now I am NOT suggesting pushing people to the point of breaking exhaustion. It may work for a band on a budget, but would kill the spirit of an office. What I did find interesting is that last line – “We failed until we didn’t”. That is exactly how humans learn to do anything. So why would we punish a team or person for trying something and failing at it? We need to built an environment where it is safe to fail. Try something, if it doesn’t work find out why, learn from it, and try something else.

For example I have always enjoyed creating and changing Agile boards. We can add a swimlane to try something new. If it works GREAT lets keep it and move on. If it doesnt work, why not? Are we missing something else? Often you find out a lot about your team and ways of working by failing on something.

How do we capture these failures and learn from them? Regular retrospectives. If as a team we can meet up and figure out what works and doesn’t, then we can keep improving. I have seen this work for a lot of things. Maybe a team wants to try using a new tool? They can set it up and test it over a week or two. Then have a retro after and see the pros and cons on using it. I have found this not only improves the overall product but allows teams to feel empowered and to keep discovering and learning new things.

Making sure your team members are not afraid to try something is really important. We want our teams to feel like David Bowie, “No, I won’t feel afraid, I won’t be afraid anymore”


Atari : Or how I learned to stop putting pressure on teams and trust people


I recently watched the documentary Atari: Game Over. For those who have yet to watch it, it’s about the Atari games engine and the rumors surrounding the dumping of the ET game. I would highly recommend everyone watch it. What I found most interesting about it was the company’s attitude towards its staff. There are interviews with old staff members. It seem Atari was the cool place to work at the time, and why was this? They left their staff to pretty much their own devices. There was nearly an “anything goes” attitude, once the work got done. This allowed for people to have fun and try new things. What happened? Work got done! Not only that, but the developers made some of the most popular and best selling games at the time. Some of these games took 6 months, some took a year, but the finished product always seemed to sell well. Along comes the ET film and, with it, a great idea for a new Atari game.


This is where the pressure increased. Suddenly this game was needed for the Christmas market. Rights for the game were finally obtained in July, thus giving the developer (Howard Scott Warshaw) only 5 and a half weeks to make the game. This is a big difference from the 6 – 12 months he had to create some best sellers of Atari’s fame. The game is regarded as the worst game ever made in a lot of reviews. Personally I think that’s a bit harsh, knowing the developer and the deadlines. But it was the start of the end for Atari. What can we learn from this? Well a lot of people would say that the game should have been better. There were some bugs in the finished product, making the game an overall frustrating experience for the user. So, I firmly believe given the same amount of time as previous games that ET could have been much better and a massive hit. The pressure put onto the developer, to create a game under such a deadline, was a massive mistake. The more pressure, the easier it becomes to cut corners. The first thing that usually goes is testing, hence you get a bad user experience, exactly what happened with the ET game.

Sadly I have seen this happen to teams I have worked on. Best practices go out the window once there is some pressure. “I don’t have time to write tests, this needs to be live”, or “I was told to release this card anyway and we can spin up another card to fix the bugs”. This tends to happen when the teams are judged on how many cards they release per week. Suddenly its a race to get cards done by Friday. The answer to this is to focus on the value that is being released to the customer, not how many cards we get done. Pressure tends to come from above, but if we are focusing on value and each card delivers something useable to the customer then  we can build up trust and this will help to remove pressure. I, of course, don’t know the details around the ET game but I imagine had a user been put in front of it before it was released, a lot of the bugs would have been found and it could have possible saved a chunk of money.

Queen and David Bowie understood what happens with too much pressure. We don’t want to be “watching some good friends screaming ‘Let me out'”


Teams should be empowered to work and trusted to do able to do their jobs. If there is pressure try and not let the teams see it. Fix it by allowing the customer to see the product early.