Who Should you Share your Backlog With?

I mentioned last week that I’d been to an interesting meeting discussing (and challenging) a few of the Scrum ideas. One of the questions we asked was about Backlog Visibility.

We all agreed that by making the backlog visible to our customers would invite feedback and reduce the likelihood that we’d spend time developing features which gave little value to our clients (see last week’s post on exactly what “value” is). But we couldn’t shake a distinct unease at making our plans visible, it took quite some discussion to articulate why this was.

Many customers and businesses work to project plans (ours included), they have long term visions of where they want to be and what they want to achieve. We realised with some trepidation that by sharing a fluid and ever changing backlog list of ideas with these customers it would create an expectation, which upon the next meeting would lead to disappointment as we had to admit the features we discussed were never in fact developed.

In an Agile environment we want to encourage this change, we want to update our backlog to remove unnecessary items and reorder the list to put the maximum value items at the top. However when presenting this to a client it could undermine us, particularly if the customer liked several of the items we ultimately decided to prune.

We decided that this is where clear communication is key. We talked about making it extremely clear that these were items we were considering working on and not a definitive product plan. A Development Forecast we suggested, after all – no one blames the weatherman if the reality turns out to be slightly different to our expectations!

What are your thoughts, do you share your Product Backlog with your clients? How do you handle their expectations that some work they are hoping for may still be cut?

Defining Value

I was recently at a talk where one of the key topics was “Defining Value”. I actually felt rather prepared for it – after recently reading The Goal I was fairly confident that the goal of any business was to make money. So “Value” would be anything which either earns us revenue or aids in our ability to make money.

It sounds boring, but it’s true.

My point actually kicked off a lot of discussion, in a room of experienced developers the proposal that unless we’re earning money we’re not adding value was rather controversial “what about paying technical debt!?” was one of the initial reactions (and one we came back to very quickly).

Delivering maximum value is of course what Scrum is all about, the idea that the team is constantly working on the most valuable piece of work is key to the sprint framework. So to be challenged to define value was an interesting idea, especially when Pete (our facilitator) threw out the following quote things became interesting:

“As a general rule of thumb, when benefits are not quantified at all, assume there aren’t any” – Tom DeMarco and Timothy Lister

With paid for work the value is often clear, the work is worth whatever the customer is willing to pay for it. Again, work to generate sales the Product Owner can list the contracts which will be opened up by a particular feature if it was to be implemented.

Support work becomes much harder. We all know that it’s easier to retain an existing customer than to earn a new one and anyone in sales will tell you the value of upsell and good customer service. So how do we justify spending hard pressed development resource fixing bugs, answering questions and supporting our existing customers when it does not earn us any revenue?

We all agreed that the only way to quantify the value of technical debt was to look at how much time and effort was being spent in supporting it. If an area of your software is full of bugs and you spend four days of each month assisting customers using it then over the course of a year it’s worth at least forty eight days to improve it!

Support work is valuable because by not doing it you’re putting your customer’s loyalty to you at risk. Reducing technical debt is valuable because it makes support work easier.

The next time you’re working in an unloved area of code, don’t moan about it – measure it. Present the business case to your Product Owner and help them quantify the value of refactoring and improving the code. It will make it a lot easier to justify doing the work!

Redefining User Acceptance Testing

User Acceptance Testing or “UAT” is a critical part of any project. It’s where the customer takes your software into their environment, tests it and reports any issues which must be resolved before they take it into live. Development teams then resolve these issues, send the application for retest and (hopefully) get a signed off version.

I have a deep seated dislike of this concept.

I should clarify that I have no problem with customers doing their own testing – in fact I encourage it, we’re software professionals and don’t work in our application’s domain. High quality customer collaboration is essential if we are to produce a good product. No, what I have an issue with is the concept of a development, testing, and bug fix phase.

If Agile and Scrum techniques have taught us one thing it’s that we need to move away from “development phases” and towards continuous delivery with ever increasing value.

Leaving bug detection and resolution until the end of project is bad!

What then is the role of UAT in modern development methodologies? How do we achieve a signed off version without digging ourselves into these waterfall defined project stages we were supposed to have abandoned years ago?

By making UAT a continuous process alongside the development.

In my view as soon as a project begins, while the stories are still being written and the mock ups created the latest and greatest version of your application should be installed into the customer’s UAT environment. Then, while you’re working away creating the new features the stakeholders in your client’s business are testing the suitably of what you’ve already developed against their needs.

As you continue, Sprint on Sprint, Story on Story you can incorporate your client’s feedback (both bugs and suggestions) to deliver the best possible product at the end of the project. It’s only by presenting your build to the customer early that you can get this feedback. Forcing your clients to wait until your project is feature complete and signed off internally will create these heavy bug fixing phases we’re all working so hard to avoid.

A Different Sort of 1:1

I met up with my line manager the other day, a nice change to our more common video chats. Spare meeting rooms at head office are seen less frequently than unicorns so instead of sitting in the open plan work area he suggested going for a walk.

The idea resonated with me and it’s something I’m determined to try with my team. Here are a few reasons why

  • Meeting rooms are very formal, 1:1s don’t have to be
  • Fresh air and a little light excercise is good for all us office bound geeks
  • Getting away from the office environment can lighten moods and change perspectives

Now, I don’t suggest you try a walking 1:1 on a wet, cold, or otherwise horrible day but the next time the sun is shiny why not take a walk?

Have you tried outdoor 1:1s? What was your experience?