RE: [scrumdevelopment] Fixed iterations, unsure content
- I would have gone with the motto "Do just enough". If the user story is ambiguous enough to allow for discovery of substantial extra work during the sprint, then quite clearly the PO didn't fully grasp the story at the time of writing it. In waterfall that's a big problem. In Scrum it's normal. We can never know everything now that we will come to know in the future (there wouldn't be any future in that case). So my advice would have been: implement the original item and put the newly discovered work on the product backlog. It is then up to the PO to decide whether this needs doing in the next sprint or not.Many engineers suffer from the delusion that they think they know better (than the PO or the customers or the users) what will be needed in the future. There is always the temptation to over-engineer a product (not just in software). Don't fall for it. Do the simplest thing that will fulfill the original story.I would preserve spikes for stories where completely unknown territory has to be charted. Packing excessive slack into a sprint sounds like a "belts and braces" approach and smells of a lot of waste. If the PO doesn't understand a particular area, then maybe that specialist should sit with the PO and help him/her to write the additional user stories (instead of implementing them on her own).
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of DoctorArtem
Sent: 17 August 2007 12:55
Subject: [scrumdevelopment] Fixed iterations, unsure content
We are doing Scrum in a team that has several quite specialized
members. I've got a question from one of the specialist that I am not
sure how to answer.
On the last retrospective team decided to commit only to the items
they were "really sure" they can do. This specialist followed the
agreed rules and committed to the product backlog item (more of a task
in this case) she could do for sure. However, during the sprint she
realized that the original item is only a part of what's really needed
to improve. She could finish on time exactly what was agreed, but then
later she would have to return to the same issue again. She decided to
make the task in full now and then it has to be finished during the
next sprint only. The situation is somewhat complicated because she is
a specialist and the other team members can hardly help her. In fact
they are already doing more, then the team committed, because they
have some "free time", while the specialist cannot finish her task in
The question from the specialist is what is the sprint useful for in
our situation. It forces her to feel guilty, because of doing the
quality work (i.e. doing the task in full).
What I was able to tell about the other teams having similar situation
1. Whenever team feels the sprint commitment cannot be met, meet with
PO and change the scope.
- That won't work in our situation since PO doesn't really understand
things in her area and fully trusts the team.
2. Pack some reasonably big amount of slack into the sprint commitment
- We might discuss it further, but as for now she feels she is too
ambitious for it. Talking frankly to me it might also feel
demotivating if at the end of the sprint I had to commit to very
little work just in case of the potential problem
3. Accompany every not-trivial backlog item with the "spike" item to
research the real needed scope, complexity and the whole feasibility
of a task.
- Probably I failed to explain the spike concept well enough (any good
links?) and anyway how can a person be confident about the scope if it
decides (for a good reason!) to change the scope half-away?
Sorry for the somewhat confused explanation. Heh, I am asking exactly
because I am confused :)
Every advice on the situation is very much welcome.