Mr. Kanban, Scrum Isn't So Bad.

I recently a fairly decent article that describes Kanban whilst pitting it against Scrum.  While I don't know enough about Kanban to make a decent comparison myself, I did find a few issues with the attack on Scrum.

Shrinking The Story:

The original article states as a disadvantage of Scrum:

Shrinking stories forces earlier elaboration and decision-making. Where product owners could write their stories fairly generally and consider many of the details later, now breaking them down into smaller stories forces more thinking earlier in a planning lifecycle.

What the author misses is that large stories inevitably have ambiguous requirements.  This is why waterfall requires extremely long planning, and short iterations require short planning.  It would seem that the larger the story, the more upfront planning is required for that story.  That makes sense for two reasons:

1. It's useful for the product owner and the team to estimate how long a story will take.  In Scrum this is necessary for time-boxing.  In Kanban, this may not be as necessary for the team, but it will certainly be necessary for any product owner with a boss who wants to know how long something will take for short and mid-term project planning.
2. The more "meat" is in a story, the longer it will take to determine what needs to be completed before the developers and product owner can say the story is "done".  Larger stories require more time to hash our ambiguity that may exist in customer requirements. 
   

My current Scrum team runs at a velocity of 25-30 Scrum story points per 2-week iteration, yet we have an informal rul that we never take in a story larger than 8 points (13 being the next on the scale).  This is because we believe that stories that large come with too much ambiguity which causes stories to often be brought back into future backlogs for completion.  Now, some may say that such small slices lead to "useless features", but let us not forget that proof of progress is a valuable deliverable in and of itself.

What we attempt to avoid is upfront design, but what we must not sacrifice is requirement divergence or misunderstanding, especially with hostile/new product owners, or product owner who tend to micro-manage teams when given the opportunity.  Where Scrum places a larger responsibility on the product owner to manage a larger backlog, Kanban places a larger responsibility on the product owner to create more specific requirements and deal with unexpected delays due to requirement divergence.

Testing:

It’s difficult to fit thorough validation of the story into a short time-box as well. So, often testing slips into the time-box after. Which leaves the nasty problem of what to do with bugs - which often get piped into a subsequent time-box.

The simple solution to this problem is to integrate the testing team into the Scrum team and make "test" a task instead of a task state.  Now, the team is responsible for estimating the time required to test the feature right along with all other development.  This is good because it places "testability" in the hands of the developer and encourages TDD.