Posts Tagged Requirements
What’s the effect on requirements engineering when switching from Scrum to Kanban……
Or, as I should say: switching from Scrum to Lean software development using Kanban as a tool for organizing work.
Can’t say for sure what the effects are, we are only in the first week of our switch; but the following bothered me as a requirements engineer when using scrum (and in fact any other method I have used so far).
The Chaos report (Standish group) states that about 2/3 of software build is never or seldom used! This is largely due to inadequate requirements. Scrum does not seem to help much in reducing this amount of hardly used software; it is quite an efficient way of building what should not be build at all. Sure, the 1/3 that does matter is build efficiently too but this 2/3 part is such a waste.
A problem with requirements is that they keep changing. No software engineer is going to commit to velocity points for my requirements unless requirements are clear, stable, final, approved, signed in blood. Anyway, requirements elicitation does not fit in the same sprint as the realization. We have to go back to plain old waterfall planning and I just have to hope that my specs are picked up in the next sprint and get implemented before they are stale. In most cases the result is just another sprint that finishes in-time, within-budget and according-to-specifications. Well, that is the signed and approved specifications. New insights, changed perceptions, etc are not included, probably not even considered!
What I expect to win from Kanban is reduced fear for velocity commitments, making it possible for me -as a requirements engineer- to join the software development flow. I just spec my requirements, directly discuss them with a software engineer and together we do some BDD or specify scenario’s for implementation. It gets implemented, tested and checked by users and we can directly act on the users reactions in the next iteration. My expectation is that we come much closer to building the right thing in the first place.