Month: April 2016

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!

Embracing change in your project: course correction or adjustment?

“When someone says they are making a course correction that implies they are now on the correct course. It implies there IS a correct course.There isn’t. At least not one that is knowable in advance. Instead of course corrections we make course adjustments. A subtle nudge to product direction here. A minor shift to the product strategy there.

And here’s the key: We never know if those nudges and shifts are going to make the product better. Each is an educated guess. An adjustment rather than a correction.”

Source : Mike Cohn, april 2016

Give me a hoot

Jay Hyett

In the last couple of teams I’ve worked with we’ve had some time critical projects to deliver with extremely tight deadlines to hit. As a Scrum Master or Coach during times like these you need to bring a little something extra, in order to keep people up beat and focused on the tasks at hand.

Something I’ve used during times like I’ve described above is a team hooter (or bike horn). The idea is as you finish a story (or move it to done) then you should press the hooter to let you team mates and the people around you know that we’ve made some progress. This is usually followed by a round of applause from everyone in a show of support.

It’s amazing how infectious something this simple can be and quite interesting how people really do get into it. Just today I had another team ask me where…

View original post 32 more words