Product development roadmaps, integrating usability and keeping testers busy …

Halfway through our second sprint, my impediment backlog has 22 impediments in it. At least I have a purpose in life.

The biggest impediment is not having a server to build and test our code on. This is a pretty major one, which we are frequently bitching complaining about, and doing our best to convince somebody to resolve, with limited success so far. But I remain hopeful …

The next three are in relation to how the scrum team and product owners work together (yes, that’s right, product ownerS – it’s not ideal, but our Scrum team has to complete work not only on the web UI project that is our main focus but also on some internal applications that can’t be ignored).

Impediment 1: We have separate workstreams and until Sprint Planning, no idea how they fit together. Our product owners don’t really know how to combine the priorities, and can’t predict beyond the current sprint when they might get any of the things they’ve asked for.

My proposed solution: we need a development roadmap that lays out the bigger themes that we will work on. Being only two sprints in, we don’t have a predictable velocity yet but we can start predicting date ranges within a couple more sprints. I don’t plan on having something set in stone, but I haven’t read anything that says having a longer term vision is a bad idea – on the contrary, Mike Cohn’s book (Agile Estimating and Planning) promotes having a plan that represents our best view of the future at any point in time. At least, that’s how I read it.

Impediment 2: we have a visual designer and usability engineer who are not co-located. The usability engineer is based in Seattle. Time difference = -8 hours

My proposed solution: until they are co-located, they work a sprint or two ahead of us so that our sprints are not held up by slow communication loops. We need to figure out just how this works.
I’m not sure I’m 100% comfortable with this as a longer term solution. According to Scrum by the book, the team are supposed to figure out everything within the Sprint. In this current Sprint, we brought our designer and usability guru to London and they locked themselves in a room for two days to figure out the designs for the interaction and the interface. They did a good job, and I’m not sure how we could organise this any better. The developers couldn’t start their work until this was done, which seems a bit like mini-waterfall, but I’m not sure if I’m taking this to the extreme. Time will tell.

Impediment 3: Testers had nothing to do at the start of the Sprint.

My proposed solution: moving the UI design ahead of the sprint will help with this. Also, we did this a lot better than in Sprint 1 – our testers worked to define acceptance tests early on in the Sprint. I have to admit … I don’t really have any other ideas on how to fix this, and again I’m hoping time will tell …

Overall, so far this second Sprint seems to be going very well and I’m hopeful we’ll complete what we committed to – the burndown certainly looks really positive!

(an even bigger acheivement … I’ve actually written a weekly post for two weeks running!)

Should we crop the Product Backlog?

I have been following an interesting discussion on the scrumdevelopment group about whether the Product Backlog should be a complete list of every feature that the customer ever wants, or whether it should be cropped to a certain length to prevent wasted effort spent estimating items that will never be high enough priority to get to the top of the list.

It’s especially interesting to me as I’m trying to work with our product owners to construct our first product backlog as we move towards using a more agile approach for a new project, and this was a question that was asked at our organisation.

I’d been of the opinion that the backlog should represent everything our customer would want if they could have it, and that’s currently how I’m approaching it.

Our product owners represent a large number of internal customers. It’s a long term project and the people who are the customers will change over time. The scope of the project is limited, but will expand, as we are building on top of an established system.

Previous experience suggests that many ideas for features are raised by different people time after time, and I believe they should be stored somewhere so that people can see what’s been suggested previously. Reviewing the old ideas helps to refine them, and I want to feel that we are progressing, and not have the same conversations over and over.

I want to be able to show people why the thing they think is important has not made it into the priority list yet, by showing them what is ‘queued’ in front of it. If ideas come up over and over then perhaps we will start to see the ones that need to move higher up in the priorities.

I also believe that all of the items on the wishlist have some value as ideas. Each item represents some level of effort in the thought process or whatever event generated the idea in the first place, and crystallized it to the point where it could be described as a feature.

The discussions on the thread, however, made me question this. On a long term project the value of the “ideas” can decrease over time as the market changes or features become less relevant. Is this “depreciation” really “waste”?

After reading many different opinions, I came to the conclusion that I still want to maintain a product backlog that is a really big wishlist – but ensure our team also recognises some things that could cause us problems.

We will need to take care not to focus too much time and effort on the items further down the list – otherwise they really will start to represent waste – in wasted effort spent estimating or planning things that may not ever happen, or by the time they do will have changed scope.

I was encouraged to hear stories from people who have taken this approach and found it works – that the items at the top are naturally the ones that get the most focus. I hope that by sticking to time-boxed meetings we can also achieve this.

One thing I also intend to do is to ensure that any items that fall out-of-scope, or that we determine really are no longer requirements, are religiously moved off of the product backlog by the product owners.

My one remaining concern is the impact of an ever increasing backlog. Somebody mentioned the “Someday” folder suggested by David Allen in Getting Things Done – the one that tends to grow the fastest with things that never really go anywhere. Yet how many of us are brave enough to just dump it? I’d bet most people are too worried to ever throw away ideas in case they don’t come back when we really need them.

If the backlog continues to increase, it should be an indication that we need more teams – but if it increases too quickly, or if this isn’t an option, what impact on team morale? With everybody having visibility into what we haven’t done, as well as what we have, will this be seen as a negative? This could be a real problem, and it’s one I’ll be watching out for. No doubt there will be many others that I haven’t even considered yet … and I’ll keep the blog updated with progress as we try it out!