WBS and Scrum

WBS is a great tool to give a thought, especially that recently several people asked me about it. There are several aspects which might be considered...

Some people things that WBS is something totally detached from Scrum. I don't agree with this. First of all if we would show a product backlog and a sprint backlog as a structure, we could consider it to be WBS. The main difference would be related to the fact that WBS must cover 100% of the work effort what means, that we at least have some placeholders for the work which is unknown at the moment. Regarding similarities, PMI Book explains that WBS decomposition for a deliverable or a subproject that will be accomplished far into the future may not be possible. In that case the team waits until they have more knowledge (Rolling Wave Planning) - sounds like Scrum to me:).

Recently my colleague asked an interesting question. He said that he already has WBS for his project but he would like to start following Scrum, he asked what he can do with it? It depends on the WBS which he has, but most probably with small modifications, WBS items could be used as themes, stories and tasks. In addition Scrum doesn't say that you can't have a detailed plan in the beginning, it just says that it might not make sense to have one and that it might be misleading. WBS items could be helpful during Sprint Planning meetings or calculating an initial team velocity and an initial release schedule.

It is also important to remember that WBS is not meant only for PM, but it is also a communication tool, shows a customer why a project is estimated for a certain budget, verifies how well a customer defined the requirements, helps forecasting a risk, etc. In a project where a customer is against Scrum it could be used at some point, in the middle of the project to show how much effort was wasted creating it, since most probably, later on, the modified plan would be far from the original one.

Summarizing, I'm quite sure that in some cases I'll use WBS even in the Scrum projects. It is important to remember that we decide what WBS really contains and how detail it is.

How to get familiar with the Scrum

Below is a list of very good books about Scrum which I fortunately has happened to read. I always suggest them as a good start for someone who wants to get familiar with the Scrum. Every book shows something different, so I added short descriptions to the titles:

1. "The Scrum Primer", Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde
   This is a very short (around 20 pages), very well written, to the point document which gives an overview of the Scrum. It is available for free under the following link: Scrum Primer
   
2. "Agile Project Management with Scrum", Ken Schwaber
   This was the first book which I read about the Scrum. For some reason it took me the most time to read it, but I would suggest you to start with it too. There are explained basics concepts and it mainly contains real life examples.
3. "Agile Estimating and Planning", Mike Cohn
   This is another great book. I read it as the last. It presents solutions for lots of issues which might occur during a planning and estimating phase of a project.
4. "Agile Software Development with Scrum", Ken Schwaber, Mike Beedle
   This book is different then others. When I read that book I had already few years of experience in Scrum projects, I was after a Scrum training and after reading other books related to the subject. My impression is that if someone is not familiar with the Scrum, he might understand the Scrum in a bit wrong way after reading this book. But...I think that everyone should read it. It really gave me another point of view on Scrum, showed that usually you might think that the Scrum is not for you when it actually is, shows that Scrum is also about flexibility and adaptation.

Talk to people the language they use daily

Many problems occur due to lack or wrong way of communication between people. For example very often it is more difficult for a higher management, a customer or a Product Owner to follow all the hassle caused by some of their decisions. They operate daily on a different level, don't have time to go into details, especially if they don't have experience in the field. This is why it is better to translate project level issues to the language they speak daily. For example if a project uses Scrum and they changes the scope of Sprint it is good to calculate wasted hours, a budget and show how it affects a schedule.