Product backlog and Kanban thoughts

At a customer we started using Scrum a while ago. At first it
was not clear to me what type of items the product backlog items need to be. We
were for example putting all identified use cases and individuel supplementary
requirements on the product backlog. This assumed we already had identified all
use cases. Scrum seems to do this different. Scrum embraces change and with it
it accepts that the items on product backlog get split and combined throughout
the project. It even states that product backlog items will be very rough at
the beginning of the project but will get more detailed along the way. So items
on the product backlog can be of any level of detail. And it seems perfectly
fine to keep high level product backlog items stay in this level of detail when
they don’t become a high priority in the project. This really encourages  to produce the requirements
just-in-time.

A lot of scrum related blogs are also talking about
implementing Kanban characteristics into software projects. Having had a couple
of classes about logistics I know Kanban is all about minimizing the
Work-in-progress and let the chain of production be PULL based. Translating
this into the software development this would mean not beginning a task when there
is enough work to be done by the next chain in production. This would mean not
working ahead when the developers have loads of work that still needs to be
build. You would begin detailling any requirements when the bucket of work for
the developers hits under a certain limit. We hereby limit the overproduction of
the requirements people. In the logistic world this would mean limiting the
supply pile before the next chain in the production cycle. In the software
development this would make sure that there aren’t too many requirements completely
detailed which can be influenced by change. So the less requirements are
detailed the less problems we will get with change hitting the project.

I wonder how much of the Kanban principle is applicable to
software projects and how much there is already “implemented” in software
methodologies. Hopefully I will get the time to study it more in depth in the
next few months.

Some nice links about these subjects:

http://www.scrumalliance.org/articles/149-requirement-analysis-and-design-flow-in-scrum

Share this