Group items tagged

team that had some problems getting their process right

their velocity was decreasing and spirits were low. Luckily we managed to change our process by changing some basic Scrum practices and replacing some of them with Lean practices, inspired by the new Kanban articles and presentations. Productivity is now higher than ever and we can now focus on what really matters: product quality and customer satisfaction.

one major issue: getting things done. The major symptom was the frustration of management and the team with the project. The first 3-week time box (sprint) ending with about 30% (!) of all features still in progress, when, of course, they should all have been done and ready for shipment.

Doubling velocity (story points done-done in each sprint) usually means we must improve several things:

a clearer definition of done

no [known] bugs escape the Sprint

Has the team made changes that make a difference to them as a result of the retrospective?

Has the team explored a variety of different topics/areas, or do they stick to pretty much the same agenda around continuous improvement? What is the balance of change/improvement work vs. working on the product?

For example, try looking at technical practices, teamwork, or customer relationships... choose what ever seems most relevant to bound the discussion. That might help the team dig deeper and find issues that have more significance for them (now...I'm sure the other changes were significant at the time).

Second getting them to understand Story Points, a seemingly meaningless measurement, seemed to be a non-starter for them.

deal hours first This is where ideal hours came to the rescue. They were far more able to wrap their heads around ideal hours i.e. if you lock the developers and testers in a room with zero interruptions, how long would it take. I figured that once they got their initial stories estimated in ideal hours down, switching to Story points will be easy as they would have established a scale of reference to compare against. This approach worked really well. They're now into their 3rd Sprint and now that they have an existing scale, whether the number is in ideal hours or story points or dog points for that matter, it really doesn't matter any more. If you're new to agile estimating, and you're having trouble coming to terms with Story Points try this first and then make the switch later.

training strategy for a significant enterprise that is contemplating an “all in” (immediate and across the entire company) enterprise scale transformation approach

for the enterprise, a combination of team-based and role-based training that would touch every practitioner is ideal

all team practitioners receive a minimum of two days of agile training, (agile team training for the each team in the enterprise)

It’s a lot easier to estimate a story that’s small — which can lead to more accurate estimates, and better predictability.

It’s easier to plan with smaller stories. With big stories — stories that might take weeks for a developer to implement — it becomes difficult to plan a development time-box — particularly when the iterations are only a couple of weeks. It seems that only a couple stories fit — and there’s often room for half a story — but how do you build half a story? Splitting them into smaller stories makes it easier to plan those time-boxes.

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.