Archive for the ‘backlogs’ Category

I recently read a blog by Charles Bradley over at Scrum Crazy where he dissected the new version of the SCRUM guide. One item in the new SCRUM guide is funny

Scrum is free and offered in this guide. Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Yes, the high priests of SCRUM close the door for everyone who does not follow all commandments to 100%. Don’t bother to come here if you change anything. The holy truth is the only truth.

Am I the only one who thinks that there is theory and then there is adaptations we have to do to make it work in the real world?

I have been doing SCRUM:ish last year, and it works. We go along and do sprints, we do the reviews, retrospectives, planning and backlog grooming. But we also adapt to changing reality, need to fix things and need to steer away from the everyday obstacles.

I see SCRUM as a theory and a template. And as with all theories and templates I take them and change them to suit my reality.

So come on, lets do SCRUM:ish and be proud of it.


Read Full Post »

There is a really good reason why they say that the top of the backlog should be detailed and the bottom more Epic and less detailed. And when stories move up you detail them and split them into more workable chunks of work. And here is my experience of not doing so.

A year ago we were a couple of product owners starting to write stories.Ice berg much like your backlog

We had a fairly good idea of what we wanted to achieve so we happily wrote down it all and made rally sure we made it in smaller pieces so they would fit into sprints.

Then the time went ahead, we implemented the top and the bottom piles floated up, still in smaller pieces. And they were unusable. What had happened? Why could we not use them anymore?

We had during the implementation of the earlier stories made changes, made a lot of decisions and the navigation had changed.

So we found that our detailed stories did not fit anymore. They described what we thought it would be a year ago, and now a year later the reality looked different. We still had a good idea of what we wanted to build. It was just that we had to build it in a new way.

So the last weeks I have gone through all my small old stories ad combined them into larger Epics, so I had something I once again can break down into smaller stories. Just this time smaller stories that fit the reality I found myself in.

So what’s the lesson?

Don’t work too far ahead. Everything changes and we have to adapt to it. That’s the power of Agile, but you need to work it the right way and not try to be smart and work ahead too much. Be humble and realize that what you do tomorrow will affect the day after. Break down your stories when you need them, not too far in advance.

Treat it like an iceberg. You see 10% in really good detail. You know the rest is there, but as far as you are concerned it is just another 90% ice that you will deal with later (when it floats up because you have removed the visible 10%)

That is what I am doing now.

Read Full Post »

%d bloggers like this: