From: MN
Sent: Tuesday, February 26, 2008 7:26 AM
To: Santiago, John
Subject: Question about SCRUM
During our product backlog planning, we identified two non-development activities that we assigned to business analysts. The business analysts have told me that they would prefer to have these tasks managed outside the iteration backlog because they're not development activities.
What do you think?
MN
My response:
The team correctly identified one of the challenges you can run into with Scrum when you introduce non-development staff. Your BA’s are not directly contributing to the current Sprint (they are thinking ahead for future Sprints) and so they don’t really belong on this Sprint’s backlog. Intuitively we know that they are a part of the team, so what to do? Here are a couple of ideas / workarounds:
1) Remove your BA’s from this Product Backlog and all future Sprints altogether. Create a separate backlog just for them and have them organize into Sprints. They are Developers, but they are Developing requirements documents instead of software. This might be a good team for 1 week Sprints since they don’t have builds and such, plus BA’s sometimes need a little extra drive so they don’t get caught in the weeds. The downside here is that they become somewhat disconnected from the rest of the team.
2) Another option is to keep the BA’s work items on your Product Backlog and your current Sprint, but don’t count their hours in any of the Burndowns since they aren’t directly contributing development time to “potentially shippable product.” This keeps them in your status meetings, and you can still check their progress with the rest of the team.
Since Scrum is all about “self-directing teams,” you might take 15 minutes for a team discussion where you lay out the challenges, posit these two solutions, solicit other ideas and have a team vote as to the best idea to try. Your team might have some really good thoughts.
No comments:
Post a Comment