Re: [scrumdevelopment] Sprint Planning Strategy for Disadvantaged Team
- This sounds like a perfect situation for Sprint 0,Your first sprint should be all about understanding the project/code.You don't mention your sprint duration but I don't think that really matters in this instance.you also don't mention the actual number of team members.If this was my team/project I would sit down on the first day and try and break the project down into areas, you don't describe the product bu I am going to make the assumption that the functionality can be broken down into at least 5 general areas.Depending on team size I would try to put two people on every section for the deconstruction, pairing senior developer with Jr developers or QA.Target being that at the end of the Scrum the team has an understanding of the existing code and will know how to develop the rest of the plan.I know this is massively oversimplified but I don't know how you can have a meaningful conversation with the Project Owner about schedule until this step is taken.jeff
On 11/29/07, andre_simones <scrumdevelopment@...> wrote:
We are currently in the midst of implementing Scrum on a pretty large project. Below are
some of the disadvantages we are experiencing now.
- The code base is about 10 years old and is pretty big.
- All of the original developers are gone. The majority of the developers have been
working on the project less than a year.
- The entire QA team is comprised of new hires, many only 2-3 months tenured. Many of
them are new to QA.
- The full functionality of the product is not fully understood by anyone.
- The poor quality of the code is profound. TDD is nearly impossible, and a re-
architecture is inevitable (but this is down the road), as the code base is PowerBuilder
(wow, its hard to find PowerBuilder resources).
The list goes on, but these are the key points that impact the Sprint Planning session.
It took a while, but we found a strong product owner who created a prioritized product
backlog. After this, we attempted to have a sprint planning session. It was pretty painful.
In my previous teams, the team members were all very knowledgeable about the code
base and its functionality. In addition, the code was structured pretty well, so the PBL
could be decomposed relatively easily in one sitting.
In this sprint planning session, the team thought of decomposing these features (stories)
into 16 hour or less tasks as a ridiculous notion. They kept saying that they would have to
perform analysis to do this decomposition. They absolutely had no clue how to
I was deeply troubled after this. A long conversation with one of the senior engineers
(who is pro-scrum) revealed that the extreme poor code quality requires analysis of the
current code to occur to decompose. As an example, there was one feature that was
estimated at about 50 hours. I asked the engineer to decompose this into smaller pieces.
That decomposition took almost a full day. Wow. I was shocked.
This means that the way the sprint planning session is conducted will have to be adjusted.
Right now, the team will not be able to sit in a room and decompose these tasks in one
planning session. I am leaning towards having a pre-planning session. Where the team
assigns "homework" to themselves, to come prepared for the sprint planning session for
the purpose of coming up with a sprint backlog and a commitment. Over time, as the
team becomes more experienced, I think that this will get better.
I'd love to hear some thoughts of some of those who've been in this situation before.
- One of the basic ideas of Agile is that you put off doing things you don't
need to do until you really need to do them.
So I wouldn't embark on any pre-project to learn all about the existing
code before you start.
Chances are, at the beginning the choices between including this high
priority item, or that critical item aren't going to be particularly
profound. It will follow that the estimates aren't going to be a crucial
element in prioritizing. No one will care if the 50 hour item breaks down
into 8 tasks averaging 6 hours or 4 averaging 11 or whatever. Put some
ballpark numbers up just so you can get an idea how big a bite you think
you can take in Sprint 1.
The idea is that as you go along, you'll get a better feel for what it
takes. The programmers will get more familiar with the system and the
estimating will get faster, easier and more accurate. By the time anyone
really starts to care about the estimates, they'll be good enough. At the
beginning though, the best thing for the Team is produce something.
Anything. Even the wrong thing, as long as it's well done, complete,
tested and potentially implementable.
If they're producing stuff, then they're not disavantaged any more.
Lawyers' Professional Indemnity Company
- On 11/29/07, andre_simones <scrumdevelopment@...> wrote:
> I was deeply troubled after this. A long conversation with one of the senior engineersIs the team aware of the fact that an estimate is just... an estimate?
> (who is pro-scrum) revealed that the extreme poor code quality requires analysis of the
> current code to occur to decompose. As an example, there was one feature that was
> estimated at about 50 hours. I asked the engineer to decompose this into smaller pieces.
> That decomposition took almost a full day. Wow. I was shocked.
No harm is done if it turns out to be wrong, but the team will learn
to better estimate next time.
Have you considered using story points? These funny
estimating-thingies are especially useful when it's hard to imagine
every task upfront. Read Mike Cohn's book "Agile Estimating and
Basically, you look at the product backlog and pick one of the
smallest stories. Let's call that 2 story points. All other stories
also get point values: if it seems twice as big, it's 4 points. Rule
of thumb is: the larger the story, the less precise the estimate.
Therefore, use for example the Fibonacci sequence to estimate stories
(1, 2, 3, 5, 8, 13, 21, 34, etc..).
The advantage is that you don't have to think of tasks and hours, just
"how big do we think this is".
The first Sprints the team may find out that it over- or
under-committed, but this will level out as they learn to know the
system, the code base, the product owner, etc...
Hope this is of any use to you.
Martin Schapendonk, martin@...