Category: Scrum

No Backlog Policy

pawelwrzeszcz5 Comments

I hate Product Backlogs’ unrestrained tendency to grow, get messy and unmaintainable.

Backlog
Photo: Grant Hutchinson on Flickr

How Backlog Was Supposed To Work

Ideally, a Product Backlog should give the whole team a clear roadmap on work to be done.

I remember times when I actually believed this is really possible, even with a huge Backlog, but in practice in every project I worked on I struggled with keeping the Backlog up-to-date, prioritised and consistent.

Then, thanks to Roman Pichler (see Top Ten Product Backlog Tips for example) I understood that the Product Backlog requires a lot of care (well, the same way like codebase does). This includes:

  • Finding right wording for user stories
  • Writing acceptance criteria for stories
  • Managing stories on various level of detail, decomposing them when necessary
  • Removing(!) no longer valid entries from the list
  • Rewriting other ones
  • Getting stories estimated
  • Prioritising
  • and that is probably not the end of the list.

All of this done regularly!

Woow, that is a lot of work!

Reality

In practice, most of Product Owners or people responsible for Product Backlog (including myself) do not perform most of these tasks regulary, because the only really important horizons (at least in agile/lean approach) are:

  1. This iteration/week
  2. Upcoming release or other important date, usually within a couple of weeks from now

This means that what actually matters is on the top of the Backlog. All other stories are… well… you can either say “less important at the moment” or, I believe more correctly, “waste”.

No… Well, Maybe

I am a huge fan of “Start With No” approach.

NO
Photo: Nathan Gibbs on Flickr

Hovewer, over and over again I observe the following scenario:

Customer: Hey, could we have feature X in our product?

Development Team: Well… it all depends on your priorities.

Customer: Yeah, this X is really important.

Development Team: OK, in our Backlog next things to work on are Y and Z. Should we do X before?

Customer: Ah, no! Y and Z are crucial too. Hm… Maybe we could implement X immediately after Y and Z?

Development Team: Yeah, sounds like a plan. Although we will still have several important things to do after Z for the upcoming release, so we will have to see how X fits.

(silence…)

Development Team: OK, let’s put X to the Backlog and we will see.

And you know what? Quite often this X stays in the Backlog forever.

This is what I call saying “Maybe”, instead of “No”. Backlog is a safe option to close such a conversation, but unfortunatelly later on no one dares to remove anything from there, so lower part of Product Backlog becomes Idea Trash.

Possible solution

Here is what I suggest:

  • Keep very small, focused “Backlog” (better name “This week” or “This release”)
  • Put a hard limit on number stories in it. In other words, limit WIP, where story in the backlog is also considered as “in progress”
  • Anytime you are tempted to break the limit, remove less important stories from the Backlog
  • Most importantly: Have a clear working agreement that removing an item from the Backlog does not mean rejecting to do it at all. You can add such a story later when it becomes important enough.

I am using such an approach on my Personal Kanban board and I would love to give it a try in a project. Actually, this post is triggered by our hassles with managing Backlog in Codebrag and by writing my thoughts down I hope to convince my teammates to give it a try 😉 [update: We have tried it in Codebrag and it works very well]

The idea behind this is making an issue of “There is always more to be done than our capacity” more (frequently) visible. I believe that having a clear backlog helps having clear mind and making better decisions.

The argument against this approach I hear mostly is that something important or innovative might be forgotten if not written down. I disagree. If a user story really “loves” me, it will come back. Otherwise it is not worth my effort.

-Paweł

Advertisement

What a ScrumMaster Can Learn From a Mountain Guide – Preparing Breakfast

pawelwrzeszcz1 Comment

Having experience as a mountain guide helped me understand how teams work in various situations. Some of the behaviours apply to the professional world as well.

P1080194.sized
Photo courtesy of Tomasz Rosiek

Imagine you wake up on a sunny morning in the tent piched on the mountain pass. The first task for the group, after crawling out of their sleeping bags: prepare something to eat.

Process

You may count on some people being very helpful (or hungry ;)) and eager to spread jam on slices of bread, but most of your team is probably yawning or hesitating what to do.

What you need to do is:

  1. Start working – cutting the bread, vegetables, etc.
  2. Encourage others to join (inviting by name works best)
  3. Withdraw after short time, let someone else cut the next cucumber.

The most important (and the hardest) part is 3. It is easy to get involved into something, but there are probably more important things waiting for you (campfire, water supplies, plans for the day, oh, lots of stuff). If you do not start leaving work for others you will quickly end up doing more you can manage.

Tools

I have encountered it over and over again – some people do not pack knives. They are generally willing to help, but they do not have a crucial tool. I ended up bringing spare ones on each trip :evil:.

Your responsibility as a leader is to start, show an example and ensure people have everything they need to acomplish the job. After that do yourself (and your team – in the long term) a favor by taking a step back.

Retrospectives and Experiments

pawelwrzeszczLeave a comment

On team retrospectives this point seems to be the hardest one – deciding upon specific action points. Gathering data and discussion are much easier parts 😉

Experiments

Here is an approach to make commitment for the action points a bit easier – make them experiments.

Try an idea for a week and see if it works. Put a clear timeframe after which an experiment is collectively evaluated by the team.

Our case

During company retrospective at SoftwareMill we had a discussion on improving our (remote) communication and we were considering using Mumble. Not everyone (including myself) was sold to this idea, but we decided to install it anyway and asked everyone to give it a try.

What brought me round to do the experiment was Tomek Szymański‘s reply to my concerns:

“How can you say you do not like it if you have not tried it?”

Within two or three weeks of experiments we ended up with a different tool (TeamSpeak gave us better quality). For some of teams it turned out bo be their favorite communication channel, other teams decided not to use it, but at least they made a decision based on their experience instead of speculations.

How does it make a difference?

This approach is especially useful if the proposal for an action point breaks the current habit or is somehow unusual, which makes some of the retrospective participants concerned about it. An experiment is a better idea for such a case than trying to enforce a solution.

For a team making the commitment for just a week or so is much easier. And maybe at the point of evaluation (which may happen on the next retrospective) those who were concerned will change their mind.

Give it a try!

So, next time you are stuck on a retrospective try conducting an experiment 🙂 Let me know how it worked for you.

-Paweł

JAXLondon – Lessons Learned

pawelwrzeszczLeave a comment

Last week I have attended the JAX conference in London. Here is a couple of highlights that attracted my attention enough to write them down.

Product Backlog

Roman Pichler about the Product Backlog:

Low-priority backlog entries should be much less detailed than those on top.

When (and if) their time comes, they will be probably split into smaller stories. This also shows that the backlog is something designed to be often changed (and reviewed!).

Why do you need to allocate time for gathering requirements/design/architecture work every iteration?

Think about the Waterfall approach and all the work done in the initial project phase, before coding. When following Scrum methodology this work still remains. The only difference is that it is now scattered among the iterations.

Guess the number

Jason Gorman came up with a great exercise during his Keynote. 2 teams were trying to guess the 4-digit number, taking turns.

? ? ? ?

One team was made to guess the whole number up front, while another one were free to guess it digit by digit.

Now, Dear Reader, guess who was able to figure out the number faster and which team represents the Waterfall and which one is Scrum 😉

Jason also pointed out that when building a software solution “how fast we learn is actually more important than how fast we deliver”.

Measuring effects of TDD

In the introduction to his talk, Keith Braithwaite showed a correlation of Cyclomatic Complexity values against the probability of faults being found, which I find really useful to convince myself to think twice before adding another “if” into code. And, yeah, at some point the probability reaches 100% 😉

Keith’s analysis of Cyclomatic Complexity distribution in various open-source projects proved that in the tested code one can observe higher preference for less complex methods, though there still remain parts of code of high complexity.

What is more, a nicely TD-Designed project’s code needs somehow express the same behaviour as the codebase with lots of “if” statements. How is this richness achieved? Well, maybe we trade off here more interactions (and greater coupling!) for less “ifs”.

We are all lazy

Last but not least, I found one explanation on why writing tests leads to shorter methods really interesting. Long methods may not be hard to write, but they make testing difficult. Big tests are hard to write indeed. So, when it comes to writing (long) test cases, your laziness forces you to… refactor for smaller methods, cause this will simplify testing!

The best presentation I have attended on the second day was Thinking Distributed to Improve Agility by Jamie Allsop, but… that is another story.

Daily Scrum: The Fourth Question

pawelwrzeszczLeave a comment

Let’s face it – Daily Scrum happens to be boring meeting sometimes. In the long run it may turn out to be tiresome routine, even for a team that understands its importance.

To make our meetings at SoftwareMill more interesting, we have implemented the idea of The Fourth Question, which I want to share here.

What is the question today?

Basically, apart from the usual three questions (Done yesterday. Plan for today. Blockers.) each member of the team answers additional one. What is the Fourth Question? Well, that is a good question 🙂

The question is announced by the ScrumMaster, who is free to come up with any question they like. This may be something connected with the project or personal.

Each day the question is different. Since in our team the person that leads the meetings changes every week, each member of the team has their chance to ask questions.

Examples

Here is a list of various questions that appeared on our Daily Scrums:

  • How are you feeling today?
  • Which day is the most effective day for you?
  • How useful this meeting is for you?
  • What have you learned recently?
  • What is your favorite shortcut in our IDE?
  • What should we do with people coming late for Scrum?
  • What did you have for breakfast?
  • What is your favorite movie?
  • What board game did you play recently?
  • What gadget have you bought or received recently?
  • What sport did you practise recently? (And when it was? ;))
  • Ideas to spend time with a child in winter.

Since we are a remote team, we have also asked each other questions like:

  • What type of the office chair have you got?
  • What have you got on your desk that is not connected with your work?
  • Do you listen to the music when you work?
  • How are you making notes?

(Authors: The Whole Team)

Areas of application

This technique

  • is useful for coaching
  • stimulates knowledge sharing
  • will help team members to get to know each other
  • will definitely introduce some fun and diversity 🙂

Guidelines

Of course having one more question might lead to the longer meetings, but with a little bit of discipline it is still possible to keep 15 minutes limit (If this gets difficult you can always ask “What can we do to keep the limit?” ;)).

It is a good practice to announce the question some time before the Daily Scrum. People will then come with the answers ready.

We favor simple questions that can be answered in one sentence.

Give it a try

If you like this idea, do not hesitate and introduce it on your next Daily Scrum meeting. Let me know how it worked in your team and what were your questions.

Have fun with the Fourth Question!

-Paweł

PS See also Łukasz’s post about this idea.