Prefer swarming over a mini Waterfall in your sprint

I have worked as a business analist on a project where it was our task to ensure that there were enough user stories ready for the team to start working on. We put all the details in the user story (mock-up, full description, acceptance criteria),  so they could be presented and estimated in the sprint planning , and developed and tested in the next sprint. Of course sometimes we had to adapt the user story based on some comments in the sprint planning but we managed to have them fully fledged before the sprint started.

Not surprisingly, the team came up with new questions, instigating the product owner to invent new great ideas or exposing some flaws in our up-front analysis. But there again we managed to adapt the user story’s description to meet the new requirements just-in-time.

An inspiring recent article from Mike Cohn  made me start thinking that the approach he suggested was not what we had been doing. We had actually been applying a mini waterfall in our sprint by doing too much up-front analysis and did not foster the principle of gradual insight and team swarming. At that time we assumed that at least we followed the just-in-time paradigm by not analysing all product backlog items up-front but only the items that needed to be ready for the next sprint. Mike opened my eyes that the definition of ready should not violate the principles of swarming and overlapping work. Like Mike suggest: plan 2/3 and discover the other 1/3.

“The dev team determine they know just enough to get started and then start. As they work they pick the next micro-thing to do by deciding do they know enough to do that thing or would time be better spent gaining knowledge”.

Thanks Mike!


Rewording the “want to” phrase as the “so that” phrase

“As a user, I want to be able to access my client list so that I can view my client list.”

Getting to the value part of the user story right is often tricky. Without proper analysis you can easily end up with a story that describes what you are building, rephrased in 2 different ways, without answering the “why.” In the user story example above, it doesn’t describe why the user wants to view the client list. Making sure that there is an answer to the “Why?” is important.  ~ Sprintly