Bad Story Spotting

Today, I was having a chat with a few others. It was long and rambling but the conclusion was kind of nice. We realised that every single issue we were talking about really started with how we prepare our stories. We often have bad stories that make it through and then we have to deal with the problems in the sprint, which is terrible for everyone concerned.

So we came up with 3 ways of spotting a bad story rather than trying to decide what a good one would look like. All have to pass for this to be a story that we should do. The vision was that the team can 'test' a story before allowing it to be worked on ensuring the team have the final call on responsibility.

1) Does it have any assumptions or risks?

No.... none? Don't believe it. It would be a truly exceptional story that has neither of these. If there are no risks then I would bet that this is either too small or there is no value in the story. Neither are good. The most common reason is that we simply didn't think or come up with any, which is not the same as there not being any.

If there are some assumptions and risks then we should find out if we are happy with them. Can we mitigate the risks we have identified? Are there any experiments we can run to find out some more? Are the risks worth it and we are happy with the trade off (which will probably be longer delivery time)?

Spotting assumptions in a discussion is actually very easy - "Well, IF we did this...", "What about..." or the clanger "Assuming....". Stop, ask for it to be a sentence and write it down!

Risks require a little more effort. We have some questions we can asks "What is likely to take the longest?", "What have we not done before?", "What is only known by a few members of the team?". Using Liz Keogh's scale for estimating complexity is a nice tool too which should help you uncover the risks of key parts of a story.

2) Do we all see the same thing?

I was introduced to a great game in a workshop with Tobias Mayer. You create a character by each person in your group adding one feature at a time. When you can no longer 'see' the character, the next person has to explain how the character makes sense to them - this is to help you see it.

At the start of your story or during planning, you can call out what you need to do for a story in order one person at a time. If anyone does not see the same thing you can challenge by saying that you cannot 'see it', allowing you to spot if things are missing. When we cannot think of anything else to add, we can check that we all 'see it' and move on.

You can also do this using diverge and merge if you task out stories. This where everyone creates tasks and then we merge these together to see where we agree or have different ideas. Both are valuable - similarities suggest something we should definitely do whilst singular tasks merit conversation since we might have missed something.

If we don't see the same thing, we need to spend a bit more time making sure we do. Doing this with the people who will actually develop the story is absolutely required. Extra points if you are using the 3 Amigo's for this conversation.

3) Will this take longer than...

Yes, estimates suck. This isn't quite that. You pick a line in the sand and you decide that stories should not take longer. This is your stories delivered and everything that entails. For my team, at time of writing we are trying to get everything into production in 5 days or less. We are miles off but that is our line in the sand.

To reach the hallowed land, our stories need to be smaller and the line in the sand helps us recognise stories that do not fit the goal.

You need to take constraints into account. We know our path to live is not a super smooth highway so we take that into account and ask, "Will I be done with development in 3 days?". If not, then we need to break this story down, it is too big.

You can also use the awesome "No busllsh*t" cards from Lunar Logic, which approaches this from a different angle.

Now that's what I call a plan.

Creating a bunch of stickies never felt like a satisfactory result from planning. This is a reflection on the progress made by one team to create a real plan of how to convert story into software.

Stage 1 - Creating tasks without conversation

The team's planning session creates stickies for various tasks that we need to develop the feature. This is led by only a few of the developers and it is almost entirely directed by them. The stickies represent pretty big elements of work and the estimates are pretty high - most are over a day in length. There are very few testing tasks, which are created by the QA guy only.

Observations:

• The team aren't thinking how to do this work - someone else has decided and are dictating the tasks as they see them
• The tasks are not very granular so detail is being missed and the resulting estimate is not very accurate
• The team is not owning the QA - they are creating 2 teams which might not join up to deliver the work

Stage 2 - Experimenting with Diverge and Merge

A recommendation from our Agile Coach gets the team using Diverge and Merge to create tasks. The whole team creates tasks in parallel and then they merge their stickies. This breaks the dependency on individuals leading and makes everyone think about what needs to be done. Merging creates conversation as some people think of things that others haven't and we all reach agreement where we have the same tasks. To make this work, it is need to follow the work through sequentially. You can optionally play a game to see who keeps the most stickies on the board, which keeps the session flowing.

Observations:

• The team don't really buy into Diverge and Merge but the sequential story of what needs to be done makes sense to them
• Involving more of the team means we have less direction from individuals - there is more ownership from the team rather than following individuals
• QA still a secondary process within the team
• Tasks are still quite large

Stage 3 - Creating tasks sequentially

SM encourages the team to explore how to do the work sequentially, encouraging quieter members of the team to contribute. Larger tasks are broken down and things we often forget also take time are included like documentation, deployment packages, merges. The QA guy is still doing the same thing but SM asks them to explain the approach to the team, which does not result in a lot of feedback.

Observations:

• Following a linear path through the tasks makes it easier for the SM to pull developers into the conversation
• The larger tasks were hiding detail that we need to discuss in order to estimate - breaking them down helps reveal these
• Asking the QA guy to explain the testing approach helps to breakdown the 'us' and 'them' - it introduces the notion that the whole team should understand testing, led by QA

Stage 4 - Team ownership of Quality

We start the planning by talking about testing not development, which was an action raised in a retro. The team create a basic test plan and everyone estimates the test tasks. There are clear gaps in knowledge as estimates are wildly different - team estimates and indicates which tasks need pairing for knowledge transfer.

Observations:

• Talking about testing first influences the order they develop in, so the tasks are a little different.
• The testing plan being known by the team means they can shift between development and testing tasks - this gives the team more options as to how they deliver the work during the sprint
• The knowledge sharing is clear and improvements are found easily as a part of the process - no retro needed for this one

Stage 5 - Team collaborates on an approach

The team realise some stories need more thought. If left to the sprint, these decisions need to be made by a single developer rather then by using the wholes teams skills. A retro action is to use a whiteboard session to discuss the approach before a story is started. The sessions visually describe the areas of the system making it easier to spot difficulties or additional tasks that might be missed with conversation alone.

Observations:

• Pictures work better and getting people to explain using the diagram helps too
• This is very Just-in-Time - is there an earlier opportunity for this?
• Some areas of discussion maybe go too deep - the team sometimes dive a little too deep into implementation.
• A retro action from the team empowers them to huddle if they need team ideas/consensus - this helps counter only one or two developers deciding things without anyone else knowing

Stage 6 - Planning using a whiteboard

The team move the whiteboard session to planning and then decorate the system areas using tasks as they follow the development sequentially. The team discuss testing as a part of the conversation, making testing more integrated into the development. By grouping the stickies to areas of the system, they are able to see how many of them could work on the story at the same time.

Observations:

• The combination of a picture and sequentially discussing the development works nicely - it helps expose tasks the team has frequently missed
• The team is starting to think more about how the tasks could be done in parallel by picturing areas they can work on without tripping over each other
• Testing tasks are easier to spot - impacts on existing tests are highlighted quickly

This journey took quite a few sprints. There were regressions as well as advances but when I look back I saw these stages of development. The retrospectives drove many of the changes but we also saw spontaneous creativity - using the whiteboard sessions to plan against, is a good example.

The key thing I saw from the team was a shift in focus. Instead of planning how to do the development, they are now thinking about how to deliver the story. This goes further than a list things to do - it should aim to answer the questions:

• What order is best to do these tasks in?
• Who has specialist knowledge that we need to leverage?
• What does testing look like for this story?
• How can everybody assist with testing?
• How can we get everybody working on the same story?
• What do we need to knowledge share on for the future?
• What does the final solution to this look like?
• What are the 'risky' tasks?
• Who else might we need help from?

What does your 'plan' look like?

Visualising Sprint Planning

I heard a fantastic thing today:

"Well, we have a velocity of about 40.... so we should be able to handle three 13 point stories"

Let's explore how this might work using some pictures.

We can start with a box representing our sprint. We start on the left and finish on the right, exactly like a timeline. We have 8 developers on the team, who pair the majority of the time so we can see the sprint divided into 4 parallel streams:

As I blogged about previously, I know my team deliver 13 point stories 10-13 days based in previous history. Visualised, this would look like:

Not a great start.

For the purposes of this blog, I'm going to imagine we have sorted this issue and the team have a track record of delivering 13 point stories within our sprint window of 10 days. So going back to the previous statement, we can view the sprint like this:

First obvious issue, what would the last stream be doing? OK, so we had some spare capacity - according to our velocity we had 4 left over so we could bring in a 5 point story and still be OK. Five point stories are taking about 7 days:

We have a little slack, which is never a bad thing. However something more sinister is going on - these developers will not have many options to deliver this work.

The pairs on 13s will be stuck with that story from beginning to end. Everyone else has a similar problem.

We have 4 stories in play. 3 will probably finish around the same time, which is right at the end of the sprint. We only have 2 developers at the end to help get these stories across the line as far as testing goes. One developer on each story could mean one story is sacrificed.

The numbers and stories 'fit' but this is less than optimal and still pretty scary.

If we can, we aim to finish stories mid sprint. This allows us to mix up the teams skills or to add resource to another story if required. In the previous example, although we could try to do this we risk not delivering the stories at all.

So if we could break down the stories a little, we could also assess risk and decide when to start a story. In the following example, we have a big 13, two 5's and a 3 all in progress:

If everything pan's out the guys working on the 3 will finish in time to help out with both of the 5's or start another story. Alternatively, they could help out with the 13 if we feel there is more risk in that not being completed.

With the 2 fives being complete, we could swarm on another story that we tasked out specifically to allow more people to work on parallel or we could mix up the pairs and pull in 3 smaller stories - probably a 2 and a pair of 3's might fit if we look over our lead times. Merging 2 of the streams and working on 1 story would lower WIP, which reduces lead times which is another option.

Alternatively, we could benefit from a bit of slack and allow the team to evolve their development practices. Seeing that they are no longer working from beginning to end, we have that option also.

All these options start for us in prep and planning. Our choices on how we break up and task out stories allows us to plan how we are going to deliver that work. Just relying on numbers is way to simplistic. Knowing a bit about your leadtimes gives you pretty powerful ways of visualising how the sprint should pan out.