Comments on: Step 3: Sprint Planning (Requirements)

By: JH

JH — Fri, 06 Jul 2012 09:16:42 +0000

What I find really hard with Scrum is the isolation it creates within teams. Yes the team is cross-functional but it doesn’t mean that everybody can do everything. It simply means you have the right amount of disciplines in your team so complete the project.

Let’s say your team consist of 3 developers, 2 tester and an analyst. The team velocity is good for 40 points. Theoretically we say “Ok, the team velocity is 40 so the team can take approx. 40 point of User Stories in the upcoming Sprint, but that’s not entirely true right?
Because that 40 points is related to the nature of the work being done last sprint. 40 point for 1 sprint isn’t really the same as 40 points for another sprint, because the emphasis could be totally different.

For example:
Sprint 10 was complete and the total amount of points added up was 40. But Sprint 10 had a lot of development work in it.
Now Sprint 11 is coming out and the team knows that there will be a lot of bug fixing and analysis so it’s in my opinion not realistic to commit to the 40 points…
So you’ll be ending up doing some micro managing within the Product Backlog and try to add Development tasks in the new Sprint (which could be lower in the backlog then the other stories)
I was wondering how you guys deal with this.

By: GI

GI — Sun, 03 Jan 2010 14:00:11 +0000

If we detail requirements one at a time, just in time, we may miss conflicts or duplicates in the requirements.

If we do all design for requirements one at a time, we are more likely to miss common solutions and duplicate code.

We certainly don't want to go waterfall, and document ourselves into paralysis, but some requirements specification and top level design should be done up front for iteration features.

In XP you actually do some requirements detailing up front, since TDD story tests are requirements.

By: SNP

SNP — Tue, 09 Oct 2007 17:13:00 +0000

We look at duration from the perspective of the number of items that will be delivered. Not sure if that is a good approach, but it seems to work here.

The situation is altered if there are any mission critical items that need to go at short notice, which then goes outside the SPRINT.

By: Senf

Senf — Mon, 08 Oct 2007 05:48:00 +0000

Hi! I’m trying implementing the Scrum method for my team. I’m a newbie in this, but it seems, that Scrum will be really effective for my team. Your tips are very helpful by the way. Thanks! I’ve also found this piece of software you can use for Scrum; it’s pretty agile and works for us so far.

By: Andy Singleton

Andy Singleton — Fri, 05 Oct 2007 05:10:00 +0000

It does seem that optimal sprint duration depends loosely on many factors. It's something that teams need to adapt in order to give themselves room to work. I like your word "comfortable".

However, I don't think the cycle time is actually very malleable. I think one factor sets the bounds: the time required for testing and stabilization.

I just posted a piece on stabilization, with this theory: The length of the stabilization period actually determines the length of your release cycle / iterations / sprints. You should allow about twice as much time for new development as stabilization. So, if your stabilization period is four days, you will want 8 days for development (12 days total), rounding up to 2 weeks.