Re: [scrumdevelopment] Re: Sprint Backlog - Several Small Stories v. Few Large Stories
Hello Michael, ... Stories not considered done makes me want to know by whom . If the PO, then I want to know why the PO was not consulted earlier. If the
Message 1 of 5
, Aug 19, 2011
On Aug 18, 2011, at 10:23 PM, Michael wrote:
1. We've been using scrum for 5 years, and there were periods where we had to work stories in consecutive sprints because they were not considered done. More recently we've become better at managing the sprint backlog and through discussions with the PO, we tend to push out other work and concentrate on getting open stories done (assuming the open stories have priority and not discovering a technical hurdle that needs a spike or other investigation).
Stories "not considered done" makes me want to know "by whom". If the PO, then I want to know why the PO was not consulted earlier. If the answer is "the story wasn't close enough to done until near the end", then I have my case for smaller stories.
2. We have had big differences between committed backlog and actual velocity from time to time. I could not find a correlation between that difference and the average story size, even when factoring in team size. I have not looked at re-work on smaller vs. larger stories, but that is really interesting.
Yes. I would also look into whether there has been pressure, whether there were common elements or common participants in the stories, and so on. There is likely some commonality to be found.
A little background - team size is 7-10 people, 3 week sprints, use the Fibonacci series story point scale, team agrees to take in stories 8 SP or less (after significant debate and choking on 13 SP stories several times). 4-5 of the team members have been on the team for all 5 years, and the most vocal proponent of larger stories is finishing his 3rd year. The argument put forward is that if the team works in larger chunks, then it will be more likely to get a feature set done before release (done as defined by this developer, not by the PO).
Working in larger chunks always decreases the chance of getting a feature set done. You can fit two big rocks in this box, but 15 smaller ones.
In addition, there are [almost] always aspects of large stories that could have been left out. If we build the same feature with a big story, and several small ones, we almost always come up with a net savings of effort.
I think you comment about seeing the 'big picture' could be at the root of our discussion. We do struggle with release planning and budgeting SP for a feature set. The development team is updated at sprint planning on the current product roadmap, however, it is not always clear where or why the trades are made. How much visibility should the PO be expected to provide the team?
I believe that the team will do better if they have an understanding of what they are trying to do. They will be able to apply more creativity in coming up with solutions. That said, the more they know about the future, the more they will need to resist building something now because they foresee it being needed later.