Dealing with Bugs

The below diagram is the basic flow that I generally adhere to when talking about when should a bug get fixed or not. This is pretty obvious – and far easier to draw than to write out.

Bug flowchart

There are of course some subtleties – the devil often being in those details.

Analysis – this is all about analysis.  Sometimes it is easier to do.  Sometimes someone needs to do some digging to work out the details.  That doesn’t change the decision flow – just that you might need to do more work to get to the decision.

Bug definition – internal issues generally really are bugs as there is usually higher communication around what features and changes are and how to handle those within the team.  For external issues they could be changes, features or plain old bugs.  I assume that that analysis is already done or becomes clear during the process.  No matter what type of issue it is – they are all subject to the same decisions.  It is often easier to put a feature/change straight onto the backlog for later planning.

The problems with not fixing bugs now:

  • One small bug not fixed now isn’t a problem. 100 is.  Don’t naively grow the debt by only looking at the current issue in isolation.
  • Not fixing 10 bugs may signify a more rapid decline in not fixing other issues as it gets easier and easier to justify not fixing something.
  • Not fixing an issue now may underlie a bigger problem.
  • Hanging on to issues that you choose not to fix immediately grows the backlog with low priority issues.  Generally these low priority issues never get prioritised because… they’re low priority!  Be aware of simply growing a long list of things to remember that you’ll always ignore.
  • Make sure that if you decide not to fix something that it doesn’t keep coming back.  This is even more pertinent if the team find it and the PO decides to fix it later or never but then when someone else finds it nearer your release date – for instance in a hardening sprint – and now it needs fixing.  This shows a problem with the initial decision and will cause frustration for all.

Points for bugs – if I plan a bug for a future release I generally consider it a change and want it to be sized.  We’re sizing the effort for the release so we might as well get as much data as possible.  If you’re fixing the bug before the release then at most size it to determine how much you can take into the sprint but don’t take points for it as the number of bugs you’re creating is part of your velocity and the real velocity should drop due to work that isn’t properly done being done again.  The team should acknowledge that.

Learn from the feedback – as in any agile environment – look at what is happening and try to retrospect on why the issue happened and how we could avoid it happening in the future.  What documentation or details could have been shared with the client so that they could have known that what they were asking for isn’t a bug?  What did we miss in our own process that caused it to be a bug?  Sometimes it is too easy to say it was some once off thing but many once off things could also have the same root cause – or the same solution.  Dig a little deeper if everyone simply thinks – well that was due to this one deployment specific issue that now we’ve gone through – it will never happen again.  Because it probably will happen again – in some other form.


Permission to Size ScrumMaster?

When I first heard about Scrum one of the distinct messages I heard was of a planning meeting where all involved in the product – devs, testers, business, managers, etc – all sat in a meeting and played Scrum poker in order to agree on the relative size of the work.  This translated into a beautiful scenario where everyone involved bought into how much work is being done and at what rate as they were all jointly involved in the sizing of the work.  There was no frustration at the rate of progress as the velocity was understood and the sizing was communally agreed upon via conversation and mutual understanding.

This is possible a utopia.  But it is an interesting perspective on the sizing game and group buy in.  I’m not sure anyone actually does this.

In a previous post – The dual faces of Sizing – I identified two types of sizing that may occur on a Scrum project.  I avoided the question of who exactly was doing that sizing.  Is it the utopia of all stakeholders who care?  Or is reality, necessity or practicality different from the utopian dream?  And is that utopian dream even desirable?

1. Who sizes for release planning?

Ideally you want the entire team involved.

However you might be able to get good enough with someone who is both familiar with the new stories – possibly having been involved in understanding them and writing them – and who also is highly familiar with the team’s sizing and therefore can give a reasonable approximation as a team proxy.

If you do this, measure the changes so that you can understand the amount of change for future planning.  Metrics are your friend – if you measure, and if you use the measurements effectively to become more predictable in the future.

2. Who sizes what comes into a sprint?

Going back to the opening story – should the business people be involved in the relative sizing of the work that they will not be doing.  No.  Yes.  Maybe. Maybe not.  It depends.

Here are some options – and some ideas as to why it may be good or bad.

a) Only those that actually do the work have a say in the sizing

On the one side, sizing should be an activity for those who do the work.  They actually have to do it, so how can anyone not doing the work actually say anything about the size of it?

The complication of this model is who is “the team”.  Is the ScrumMaster in the team or outside?  Is the Product Owner in the team or outside?  Is the architect who writes no code but acts as an acceleration agent in the team or outside?  It becomes difficult to differentiate who is in and who is out.

The biggest pro is now the team has defined how big the work is.  They buy into the size of the work and they will be the ones committing to doing the work.  This model allows them to have the whole say as to what the work is.

I suspect this is what the majority of teams are doing.  It avoids some dysfunctions by not allowing them to be options (like overpowering stakeholders) and it fits into the ScrumMaster mantra of “Protect the team” and “Let the team decide”.

b) Everyone can come to the party

On the complete other side, collaboration is a key agile concept, including everyone in the process increases the common buy in and understanding of the impact of the work.  These discussions can allow for increased transparency and buy in to the rate of delivering the software.  This could be incredibly powerful for group ownership of the deliverable and allow those not doing the work have a say in the destiny of the project.  It allows them to feel like they can impact the deliverable by them understanding what the impediments and the time sinks are.  This can bring the discussion far closer to allowing the customer direct input into what they actually get – not only with the final solution but also the trade-offs along the way (speed vs features, etc) – which is a good thing.

The difficulty with this model is that significant issues can arise if the relationships with all involved are not of an equal level.  If the CEO is involved with sizing then s/he may significantly overpower or influence the process which may lead to the process becoming meaningless.  If you have a dysfunctional situation in your environment then this is the worst thing you can do as it can significantly impact the team buy in to the size of the work and could be a failure in ensuring the team is protected to do the work the way they feel best.

c) Everyone who has value to add to the conversation should be involved

Is there a middle ground between options a) and c)?

The complication with option a) is that it may exclude people who have valuable insights to offer.  If you exclude the Product Owner from the sizing activity you may lose the conversation that shows that the team has misunderstood the requirement that the PO is putting on the table.  If you exclude other individuals who have value to add, you may also lose their conversations that may help in identifying the full extent of the work.

There are variations on this model – perhaps you could have the PO and/or other involved parties provide the sizing after the initial team sizing.  This allows the team to understand what they believe the work to be – while adding in the additional conversation from the PO and other interested parties after the fact.  This two phase situation would only be needed if there is a dysfunction that allows the team to be overridden by individual power structures.

A dysfunctional example – minorities must have a say!

An example of this dysfunction could be a team with 4 developers, 1 tester, 1 PO, 1 ScrumMaster, 1 Usability expert, 1 document writer all sizing the work.  If the goal of planning poker is to pick the majority view, and the tester, PO, usability expert, doc writer and SM all are voting – and they vote an 8 when the developers are all voting a 13 – by the majority view the story is an 8.  But this may be a dysfunctional decision.

In an equivalent example, assume a team of 4 developers, 1 tester.  If they are the only people voting and the devs all vote 8 and the tester 13 – again, by the majority view the story is an 8.  This too could be a dysfunctional decision.

In both of these examples – the minority needs a say.  If a tester identifies that the testing of this item – their activity – is going to be a significant amount of work on a given story then they need to identify this and the team needs to acknowledge this in the form of discussing and perhaps accepting the tester’s sizing over their sizing as there are factors that they aren’t taking into account when thinking about the sizing.  This is the point of planning poker.  The key is conversation.  The ScrumMaster needs to facilitate this activity to ensure the voices of the minority are heard and not squashed.

So should the Product Owner size?

It depends…

If the PO is going to attempt to significantly influence the team – then no.  If the PO is using the voting opportunity to show up disparities in expectations – then yes.  The difficulty is to work out the POs intentions and to respond accordingly.

The other key reason for the PO to be involved in the voting process is to perhaps engage with a discussion on how we can simplify the implementation.  But that could be done with voting or as just a conversation around voting.

The key problem with a PO voting is clearly that they often are leaders in the organisation and wield more influence in the team and hence may cause problems as a result.  Manage that, and things will work themselves out well.  In fact it may empower the team more by having the PO involved and allowing the team to see that they can vote their way and not be overpowered.  It depends on the PO…

So should a ScrumMaster size?

It depends…

If the SM is going to reduce their ability to facilitate the voting in the previous dysfunctional examples then they should not be voting as their involvement could make them appear partial to a given outcome.

However if the SM is a team member – delivering software as well (which is not an uncommon formation in a Scrum team) then they may have value to add by voting with their team role hat on.

Another scenario that I can see is if the SM is the longest serving member of the team –who has domain knowledge and understanding.  Perhaps they were team members before they transitioned to the SM role, perhaps the rest of the team is newer than them.  In these scenarios excluding them from the sizing activity may lose valuable insights.

However in these scenarios the SM could come in with secondary questions such as – I thought it might be an 8 because we may need to integrate with the old email client which has a difficult monolithic interface – what do you guys think?

To close

I’m not sure the utopian idea of everyone group hugging and agreeing jointly on the size of the work in a meaningful way would occur in reality.  It could be a good experiment.  But it might be messy.

I have always sized as ScrumMaster because I’ve had good insight into the work that the team has been doing.  However in the current organisation that I’m in, I can comfortably sit back and not size as I don’t have the history and I don’t add value to the equation for sizing yet.  So for now, in my currently role, I won’t be sizing anymore and I’ll monitor how that goes.

I noticed most POs prefer not to size – or don’t take sizing too seriously.  Either way, that’s fine with me.

The key goal is as a conversation enabler to allow deeper understanding.  That, and as a metric to help measure the rate of progress in order to approximate the range of potential delivery dates of course!

The dual faces of Sizing

There are two distinct phases of sizing that can occur on your average Scrum project.
1. Sizing for release planning
2. Sizing for taking into a sprint
Both of these sizing activities is important and distinct from the other.

1. Sizing for release planning

The goal when sizing for a release is to get a gut feel of how big the release is in as quick a time as is reasonable / responsible.  Activities such as Magic / Affinity estimation are invaluable as they allow a lot of stories to be estimated in a short amount of time.

The goal is not to lock down the sizing or to discuss the implementation or design in details nor to look for minor flaws – though it might be useful to point out obvious ones early.  The main goal is to get a gut feel of how big this thing is in order to make some decisions and hopefully understand how long it will take if you start working.  Sizing at the release level acts as an aid to help you keep sort of on track.  My experience is that for 3-6 sprints of work this is good enough to deliver to.

Sizing for release planning is always on a good enough basis.  The team will always be able to revisit the sizing once they have had a longer in depth discussion about the content in a grooming session or SP1.

2. Sizing for taking into a Sprint

The goal when sizing to taking a story into a sprint is to make sure the team understands the story well enough to confidently say that the story is a given size relative to any other story in the release.  A key component of this sizing exercise is the conversation that occurs when the team sizes the story with Scrum poker.  It is important for the team to have a conversation if there is a disparity in what each team member believes the size is so that the team’s knowledge and understanding can grow about the work they are about to do.


If an estimate comes from the initial release planning estimation – then resizing should occur when the conversation about the story has happened in grooming or sprint planning.

If the sizing comes from a previous estimate made in grooming or sprint planning then the size should only be changed when new information comes to light that effects its relative size to other stories.  This helps reducing sizing churn as everything is relative to each other.  Resizing a single story without any new knowledge would then affect other relative sizes which may have an unintended ripple effect on the size of the backlog that doesn’t make sense seems as it is all relative – and the velocity is relative to it as well.

If a team starts a story and discovers new work while working on a story that was not included or couldn’t have been anticipated in the sizing of the current story a new story should be added to the backlog to accommodate the new functionality.  The story shouldn’t simply be resized to include the new functionality or delivered with the new unplanned functionality as both of these actions hide what has happened with the story and may lead to the story that was being committed to for the sprint not being completed.  A new story will allow the changes to be tracked effectively – and planned for in the future.  A new story will ensure that the team can continue to work towards the functionality it knows it is committing to in a sprint.

Metrics for planning the future

It can be interesting for the Product Owner and/or ScrumMaster to track the differences between the initial sizing made for release planning and the actual sizing once the conversation occurs for sprint planning.  It can also be interesting to track the amount of work missed during the initial release planning.  Both of these data points can help to inform future planning as to how much we usually change between the start of the release and the end.  This could help increase predictability by allowing the planning to take this into account in the future if necessary.

Size early, embrace change late

Early sizing is great – but don’t over complicate it with trying to make it precise.  Rather make it quick and good enough – then revisit it when you have the time for each story.  Track the amount that you increase on average over time and use that to increase your predictability if possible rather than wasting lots of time upfront and fighting the change at the end.

A retrospective on a planning talk

I gave a talk at SUSGA on Thursday evening.  The talk was entitled Release Planning with Scrum: Controlling the Chaos.  My slides can be seen here.

I think the talk went well.  I think it was well received overall.  We did touch on a couple of topics that weren’t specifically under the auspices of the talk that I’m sure I’ll blog about soon.  But the content itself seemed to be understood and generated much conversation – which is largely the point.

I did learn a couple of good things

  • When I know my content, I’m okay at presenting.  This is good 🙂
  • Karen had a great comment of how to deal with sizing of epics when turning them into smaller stories. Simply generate only as many stories as fit the number of points. Once you’re over that amount – either cut stories, or admit scope creep.  (And I would add – measure to understand the growth)
  • I don’t necessarily tow the party line in my view of certain topics.  I’m sure I’ll blog about some of those soon to explore both my thinking and hopefully get feedback from others.  That interaction/conversation in my mind is largely the point of why I blog so I’m sure it will be fun.

I would do a couple of things differently

  • I should have written up bullet points on the points that each group brought up so that they could be remembered and blogged.  I intended to, but I only remembered half way through the discussion.
  • I would touch a bit more on release planning versus releasing software – i.e. when you’ll get something versus when something will be live.  You still want to plan to know in a ball park manner how long it will take to get something specific even if you release software into the wild every sprint.
  • I practised a lot – which is great.  But based on that practice I should have changed my slides as by the time I got to the presentation I knew all the points around the points on the slides so I could possibly have achieved less PowerPoint hell.  Perhaps next time I’ll create two sets of slides – one to practice until I know what I want to say.  And the other the cool image laden slides that I can talk about.  Something to think on.  I’m not presenter type so I’ve got lots to improve around this.
  • I suspect one or two people do release planning very differently.  I should have stressed that this is the way that I have done it, and that I’ve found success, but by no means is this a blueprint for the only successful way to do release planning.  Between the PMI comment (that this is “practical agile”) and the comment that the talk was good as I presented my content well – there were certain people who possibly think what I’ve been doing is overkill and maybe not agile…  but I’d love to hear what the other options are in helping stakeholders understand and take part in what is happening.

The interesting thing is I wasn’t nervous until the hour or so before the talk.  That is progress too. I’m starting to get better at this public speaking thing.

Thanks to everyone for the support and positive vibe of the evening.  I think it was great.  And hopefully it inspired some ideas, thoughts and conversations in the community that we are.  If that is all that happens, then I’m happy.

And thanks to the Yellowtail crowd who made it out.  It was really great to see you all again 🙂

I want it by October

It is often the case that a client or a boss (or his boss and so on) comes to you and says “I would like have the Foo module by October”.  There is generally very little technical understanding of what Foo may be.  Often there is very little business understanding of the scope of what Foo might be as well.  So what do you say?

Step 1: We can do something

There are a myriad of options.  Yes. No. Maybe.  What is Foo? I’ll need a full spec before I can commit to anything.  I’ve said them all.  I’ve worked with them all.  None of them make anyone completely happy.  In general – if the date is in the future – I now go with “Yes, we will be able to do something, I’m just not sure yet what exactly that will be.”  So that isn’t no, but it isn’t yes either.

The problem is that no one may know what Foo is yet.  So how can you with provide an answer to this question with any amount of value?

So we’ll be agile about it – and if we prioritise well – we’ll get the right things done.  That is what our track record says and we’ll continue to do it.

Aside: What if “something” isn’t enough?

But what if there isn’t enough of a Minimal Marketable Product by the date?  Do we work harder?  Hire more people? Fire some people?  “We don’t know what will happen when you add 2 people to the team” isn’t a particularly useful answer but it is the correct one.  The business side of the equation needs to understand that as well.  Adding more people is well known not to be a short term solution – even if you can find people good enough to add.  We need to work to manage demand and optimise the flow of delivery.  Everything can’t be delivered in October – unless we only do one release a year – and then it becomes “which year?” 😉

Step 2: Define what it is

In the past I have worked starting with the one liner of “I would like Foo completed by October”.  From this often an RFC is initially written up by my PO.  I’ve worked with the PO to generate a list of stories.  Most recently those stories  arrived with no input from me.  Based on that list of stories we can now start discussing both what is missing and the realities of what it might mean.

Step 3: Size it

At a point where we believe the backlog is defined enough (which may be quite early) we then do some sizing.

I have in the past done a 4 hour estimation session – 2 to 3 minutes per story – with the whole team.  It was unpleasant for all concerned.  Since then I’ve done affinity / magic estimation and it works like a bomb.  In the most recent session I tried to compare my estimates made before the team did the sizing to that which the team came up with.  They were pretty close – and as the team progressed and resized items as they better understood them they came far closer to my  original sizing.  But I haven’t yet used my sizing for initially planning yet 😉

Step 4: Plan and forecast

So now we have a backlog and sizes have been applied by the team to the items.  This is very rough!  But it is good enough to manage within a couple of sprints – assuming that there isn’t a lot of unexpected work.

From the size we can take average, highest, lowest, last velocity achieved for the team and provide some forecasting as to how long it will take to deliver the known work.  Generally I’ve been working in 3-4 sprints worth of work and this has been relatively reliable within a sprint or so.  So you can agree on a reasonable date based on past experience of the real velocity and padding for stabilisation and backlog growth where you needed.  Everything changes, so expect a little change – but sometimes the client / boss would like you to not – in which case show the change visibly in order to show why you should have planned for it in the first place.

Step 5: Manage expectations transparently

From here on out I report on progress with complete transparency.  I report on change – up and down.  I report on actual work completed.  I report on the amount of remaining work and how that may have changed.  I work on how the last sprint has changed the average, highest, lowest and last velocity and how that influences the potential end date spectrum.  I report on this Every Single Sprint.

Practicalities: Sometimes you need a date, but try not to

My current process that I’ve been using for the last two years is possibly not very agile.  But when a date is asked for and that is what the client / boss is managing to then you sometimes need to provide one.  And then you possibly need to argue what to change in order to stop managing to the date.  I’ve (maybe) just won that argument – but we’ll need to see how that project continues.

Step 6: Replan every sprint – the numbers don’t lie

The beauty of this is that the numbers don’t lie.  It is simple as that.  We can be hopeful and optimistic and plan on the best velocity – but if we’re consistently not achieving the best velocity that will continue to self-correct every single sprint and the end date will move accordingly.  If we don’t discuss the information that is radiating out of the figures then we have our heads in the sand and we’ll fail.  Managing the expectations continuously and early will ensure more probability of success.

Step 7: Be Successful at what you know

Success is a relative term.  Managing expectations and ensuring that we’re successful with delivering what we know ensures that we’re successful.  Managing the change so that we can be as agile as the client / boss will allow us to be ensures that we’re successful.  We can’t do magic.  But we can manage the reality or what is actually happening Every Single Sprint.  And everyone can embrace change and be successful.  Or fight it – and hope to be successful despite the need for change – it is possible.

Are there other ways to plan?

Of course there are. There are vast options on the planning tree.  When it comes planning without involving the team there are many options.  At my current organisation there is a magic spread sheet that turns input into days based on numbers of developers to understand a guess at the size of the work.  The bottom line is that no matter what the original plan is on day 1, there is a good possibility that it will change at the end of the first sprint based on the feedback cycle from that sprint.  Embrace that information and deal with it rather than hide it and pretend we’ll do better next sprint.

Scrum provides an amazing opportunity it empirically measure progress and hence reset the planning at the end of each sprint.  Ignore it at the risk of failure.

But is it agile?

I’m not convinced that what I’ve done in the past has been very agile.  The PO and myself have done a lot of preparation work in order to ensure that the backlog is defined enough and able to be sized.  All the stories are small enough.  We haven’t been looking at epics.  This can take a reasonable amount of effort and be wasteful.  But it avoids including the full team until a full understanding of what is wanted is obtained.

Recently we’ve had the scenario where the RFC was understood but wasn’t “signed off” so we couldn’t start working on it – despite knowing that there were solid chunks of work that were very unlikely to changed.  That is waste and not very agile at all.  That is one of the things I’ve been frustrated about and have wanted to change.

Recently the PO has started working more closely with one or more team members to define the backlog better.  It will be interesting to see how that pans out with a more collaborative generation of the backlog.

I’ve also pushed very hard for us to be more agile about the requirements definition.  Let’s work it out as we get there – let’s rather embrace a little more ambiguity in order to avoid the in depth up front work for the PO and stop fighting the ambiguity as the RFC isn’t perfect.  However we do work in a remote scenario so this might turn out to not be such a good idea if the PO isn’t always available.

Equivalently with ambiguity comes less predictability on that Big Date that we may be managed to.  However I believe we have an agreement that the date isn’t usually an important feature so we should stop managing to that.  And get some of that continuous delivery going with more releases more often.

Aside: Are dates reasonable?

Is the original question reasonable?  Of course it is.  A CEO wants to make a deal and needs to know if something is possible.  A managing director needs to move forward with a product and needs to know if a certain client can be supported in a certain timeframe.  A managing director needs to be able to calculate the ROI for two different streams of work and hence needs to know the relative sizes of the work.  These really aren’t unreasonable business requirements.  But they all need to be weighed up and balanced to ensure that in the timeframe required we can deliver the highest priority items for the business.  That should always be driven by the business.  But the business should still ask us before committing.  And we still can’t do more work than we’re capable of.

Step 8: To close…

This is how I’ve been planning.  Continuously feeding back on the progress.  Get the client / boss to understand what that means.   And fight the fight when it comes to a head that the “date” isn’t in the planning – or hit the date because the velocity calculations make the delivery vastly more predictable than other methods so you can actually get the date right – or even deliver early.  Rather do that than deliver late.

I’ve had really great success delivering predictable releases with the above.  There is no magic.  Just a little maths, a lot of measuring and strong will power to help the client understand.  Hopefully this can help others to be more successful as well.

Retrospective Analytics – Sizing and Bugs

A Problem with Size?

In How do you really know enough I mentioned that one of my teams was gathering data around sizing.  This came out of a retrospective 4 sprints back where the team were a bit frustrated about their sizing.  They decided to track the information to determine if there was anything to learn.  In our last retrospective we looked at this data.

Problem: The team felt that their relative sizing wasn’t accurate enough and that they wanted to take a look at it.

Background: We had just gone through a process of doing a bunch of documentation for a web service.  I suspect this was a key reason for thinking this was an issue along with one or two other outliers.  Basically the team were doing activities they weren’t used to doing and were under estimating the impact of generating the Sandcastle documentation – both from a new technology that they were adopting as well as the back and forth communication that seems to always occur when getting some document to be good enough.  Fundamentally the DoD for the documentation wasn’t as clear as for coding a story and required a lot more communication overhead.

Solution: Gather data and analyse it.  One team member signed up to gather the data and when the team felt they had enough we would then analyse the data.

Outcomes: We analysed the data in our last retrospective.  The team looked at the data and determined that across all the sizing for the last 4 sprints about 70% was spot on and a small percentage was either 1 size down or 1 size up.  There were no clear outliers outside of 1 size difference.  This was interesting and the team now could determine that actually they were doing a pretty good job.

So going back the original problem – the team determined that it was more the outliers of new technologies or new types of work – such as adopting a tool such as Sandcastle or doing work that you’re less used to sizing – such as writing documentation – that was more the root cause of the sizing frustration.  This was also something that we didn’t do much of in the sprints that we were measuring.

End result:  We’re pretty good at sizing and really we shouldn’t be sweating it.  But we need to be aware of underestimating the effort needed for work that we aren’t familiar with.   And only really if we also need to provide date based planning on the velocity/commitment that we hope to acheive.

Buggy or Not Buggy?

In this same retrospective we did a bug analysis to see if we could learn something around our bug count in terms of improvements.  We’ve done this a twice already in the last year.  The first two were useful at generating ideas.  When we did the first one we were in a bit of a state and were trying to understand why exactly.  I was interested to see where this one would go.  Again this was driven by the team wanting to take a look again.

Analysis: We do all our internal bugs as red stickies on the board.  This makes it visible and we don’t waste time in Jira dealing with bugs but rather with the visible board that the entire development team can see.  In order to do a bug analysis we gather the issues from the last X sprints, create several buckets that we think the bugs could fall into (technical debt, UI, functionality, DB, process, etc) and add / remove buckets if needed as the process continues.

We then do the equivalent of affinity estimation / magic estimation for bugs.  Each team member gets a selection of bugs and they place them in the relevant buckets – or create a new one.  We don’t do the silence thing seems as some of the bugs are a little opaque in their wording (or hand writing) so sometimes you need to ask for reminders about the issues.  After the first pass everyone sees where everyone else put the bugs to determine if they agree – and so things move around.

Once equilibrium has been found we then break the buckets into critical and non-critical and generate insights as to what the data is telling us.

Outcomes: As it turns out we have quite a lot of issues that are UI issues – but many of them are changes but we still mark them as bugs.  We resolved to not do that moving forward so that this would be more obvious as to real bugs vs. change that we’re happy to do.

We also determined that we weren’t learning anything new.  One of the outcomes of a previous bug analysis was to do more developer testing to ensure the quality of the story.  This was brought up again and the team resolved to do more of it again – but that is a less quantifiable action – test harder / more.  Sure we’ll try.

End result: We determine that the number of bugs coming up in sprint was an acceptable level.  If none were being found, that might be worrying in terms of what did it mean.  The team were dealing with them and things weren’t being left undone.

We also determined that the more interesting thing would be to look at a bug analysis of bugs that have made it into the wild after our next release.  Those are bugs we did not find – instead of did – and it might be far more interesting to analyse those holes.  The things we have to look forward to 🙂

What? No Actions?

So the retrospective ended with the team feeling good that actually the world was pretty good.  This was great.

The devs then sat down after the retro and generated actions to attempt to get our unit testing in the current module working for the next sprint as that has been an ongoing retro action that isn’t getting traction due to some limitations that take time to work around and the team aren’t seeming to get these solved with baby steps – but more on that later.

So yes – still actions in this self organising team 🙂

How do you really know enough?

Every now and again we discuss failure to reach a  sprint goal – or just how our sizing is going.  Currently a team that I’m working with is tracking whether their sizes  were higher or lower than they expected so that they can gather data to learn more and possibly understand how better to size stories.  When these types of discussions come up,  inevitably the level of detail specified in the story is held up as a problem.  There is too little.  It hasn’t been thought through and specified
enough.  We spend too much time talking  about details that we discover when we’re in the implementation of the story.

Every now and again – less frequently I think – I get the  opposite discussion where developers push back on too much detail as a solution  is being presented instead of a problem to solve and the developers lack sight  of the business intent.

I find this a continuous balancing act.  It is a balance that I haven’t perfected
between my team and my PO yet.

We recently have had the former issue again – “too little  information”.  In previous retrospectives  we’ve started tracking our sizing.  I’ve  also encouraged the teams that if their understanding of an issue changes – we  either need to re-estimate – if it isn’t in the sprint yet – or if the scope has grown in a sprint story, then a new story in the next sprint may be  needed.  This isn’t often taken up though.

In the most recent retrospective we grouped a bunch of  things under the title “understanding”.  The team acknowledged that maybe they weren’t spending enough time in SP1 & 2 in order to fully understand the work as clearly as the work was in theory obvious.  But when digging into the work requirements emerged and understanding grew and subtleties that were there all along were fully realised. This is all too often blamed on the story.  The spec isn’t detailed enough.  The PO didn’t write it down.  I spent too much time in the last sprint
asking questions and discussing things. This in inefficient…

I must be a little fair – our PO is in Europe – so the turnaround time on questions can be longer than a collocated PO.  This is a challenge.  And sometimes he also goes on leave.  But more on that in a later blog post.

This all made me think of when we were in early Scrum adoption.  I sent an article around that talked about story definition.  There was much amusement in the team around the variation of “a story is a placeholder for a future conversation” in the article. And much ridicule that it was just an excuse to write bad stories and not to spec anything.  We’ve come a long way along the Scrum path since then.  But I still get frustrated every now and again when if a perfect spec isn’t supplied and someone needs to try and work it out – either from how it works now – or from discussions with the PO – that this is bad requirement specification and someone should have spent vastly more amounts of time working on this earlier so that a conversation didn’t need to happen now.  Alternatively – someone should have documented how it worked in great detail in previous years (though it’d be out of date by now inevitably…).  Thankfully
this doesn’t happen too often these days.

So what did we do for the most recent situation?  The team acknowledged that we need to actually use SP1 & 2 a bit more effectively.  We’ve started incorporating three questions for each story that we will be more actively asking instead of passively assuming.  These are
1. What is complicated about this story?
2. What are we going to forget about this story?
3. How is this story going to be tested?

Yes, some of these should be asked anyway – but making these more explicit with the team’s acknowledgement of the problem will hopefully make them more likely to happen in more detail.  We’re hoping this will generate additional conversation that will help increase the awareness of what the work is and the subtleties that we aren’t engaging in.  We shall see.

Do others out there also encounter the “this story isn’t defined enough” complaint?  (After it was sized and taken into a sprint.)  What are
you doing to counteract this argument?  Is it all about using SP1 & 2 more effectively?  And what tips and tricks do you use to enable the conversation to be more effective?

Hopefully one day I’ll find out how best to write a story that would make Goldilocks happy – not too much, not too little, but just right.  And hopefully one day I’ll work with developers who won’t think that the story being a placeholder for a conversation is such a farcical idea.  Though I must admit – it probably would be better receive now.