Posts Tagged planning

It seems there are things which somehow managed to bypass the attention of Scrum book authors. In this sequel to my previous post on Scrum Luminis edition, I’ll try to sum up a few pieces of advice which I’ve picked up during my Luminis “learn Scrum” stay and which may come handy to other Scrum beginners.

Project bootstrap (context = fixed-price contracts):

1. Initialize backlog – use RFP, client-supplied requirements doc, customer talks, whatever.
2. Sketch hi-level design with functionality blocks, so you know which blocks will handle what requirements.
3. Optionally re-phrase requirements to increase information value (if client-supplied is incomplete and/or technically too weak).
4. From all these sources, create product backlog.
5. Set up the team – either you have your own people (easy or the team gets assigned by client; in that case the Scrum master must work hard to get the right people for the job.

As a corollary, there is no formal project finalization stage—it is done as normal work planned for intermediate/final sprints.

Sprint goals and release not achieved

The sprint release is defined as “potentially shippable” ie not necessarily “deployed live”. The Scrum master or product owner sometimes needs to make sure there is a “product champion” on the client side who will push towards complete transition into daily use.

Also, it may happen that not all sprint goals / scenarios are achieved by sprint end. Whether this upsets the product owner depends on lot of things—priority of the unfinished, how team performed otherwise, etc. Should be however spotted and dealt with during the sprint, not only at demo meeting.

Of course, if team fails to meet high-priority needs (and spends sprint time on easy low-priority stuff) then they will, and should, have hard time at end-of-sprint demo and retrospective meetings…

Where are the bug reports?

Bugs tend not to appear in sprint backlog as stories / tasks. They mainly pop up during “in progress” or “testing” state of a task and since they are easy to repair (remember the benefits of unit testing and small increments?) they are dealt with straight away by the developer—why bother with bugtracker overhead when the bug is gone by sundown. (This is basically true even if a bug slips through after the task is “done” and surfaces sometime later.)

Or they are on functional / acceptance level and thus presumably coarser-grained. In this case they get caught by the product owner and put into backlog as improvement / rework items or possibly as reasons for re-opening a bugtracker item.

On re-planning…

Common reason for re-negotiating during planning meeting are resource constraints (not effort estimate mismatch): “For all these things to implement, we would need 5 Java engineers but there are only 3 on the team. Let’s shuffle things a bit so we can match work required with people available.”

For all changes of the original sprint plan, resulting from daily standups, you better have them documented (e.g. on sprint wiki page) – provides great traceability between burndown chart hiccups and the reasons behind them.

… and (non)estimation techniques

As one of the Scrum masters put it, “The best teams I’ve seen don’t do explicit estimates” – they use gut feeling when planning the sprint. The point is that when all is said, team commits to their plan and it does not matter how they arrive at that plan.

Yet it takes 2-3 sprints for the team to arrive at the level “we know how much we can take”, and it took Luminis about a year to get from detailed estimation and time logging to the story point and gut feeling estimates.