Last week I received an email from a customer who was rolling out Scrum to his team. Fantastic to see the team preparing themselves by learning about Scrum and asking questions before they dive in. Below is an excerpt from the original email. My responses are included below in red, including lots of questions to get the team thinking.
I appreciate you taking the time to explain how to use Greenhopper for sprint planning at the last SFAUG several weeks ago. My company has made a decision to start using Scrum. We’ve all read The Power of Scrum and we’re having our first sprint planning meeting in 2 weeks. Since my role will be ScrumMaster, I want to be prepared to guide the team through the process successfully. I recognize that making the change will not be easy, so I want to be prepared as a leader and have the tools set up in advance to minimize the friction of changing the team’s behavior.
What resources would you recommend that I reference or use to prepare me as efficiently as possible for my new role?
Some of the issues on my mind at this moment:
1. We have a couple of issue types with complex workflows specific to our business. I would like to simplify the workflows so that the work that needs to be done for each one can easily fall in 3-4 categories (To Do, In progress, Resolved, Closed). One way I’ve thought of doing this is to break the work associated with each workflow step into a subtask. Since these subtasks are often the same for these issue types, I’m wondering if there’s a way to automatically add/clone the subtasks when creating the issue.Don’t break the workflow steps into sub-tasks. Start simple with To Do, In Progress and Done.Done is your Definition of Done. Ask the team what this should be and get consensus. Is it delivered to the customer? Is it committed to the repository? Does it include unit / functional tests?Why do you need such a complex workflow?2. I’m not sure how to handle unplanned work. We are a small team, so any urgent customer issues we have to deal with will have to be added during the sprint. I remember when we spoke at the SFAUG, you commented that you don’t assign story points to bugs.
Correct, we do not assign story points to bugs. Some teams leave a buffer – say 20% of their capacity – to handle unplanned work and bugs.
If they are critical bugs that crop up then they should be in their own swimlane and have a priority of Blocker.
If they are not critical, then why are they coming into this sprint? Wait for the next sprint planning meeting and just leave it at the top of the backlog until then.
3. What’s the easiest way to deal with hierarchical relationships and dependencies between issues/tasks/sub-tasks? Before moving to AOD, I used to use the Structure plugin.
Good point, there is no Structure add-on available for OnDemand.
If you have a couple of big feature areas try using components and then creating quick filters for each of those.
4. Where do we draw the line between work team members are doing that’s tracked in the sprint and work that isn’t tracked in the sprint? In other words, do we include tasks like investor meetings, customer calls, and developer training?
Developer training and customer calls I would certainly include. It is a task. Can we estimate it in story points? Unlikely, although at least it is there for the planning meeting so the team is not over-committing to work and then saying ‘oh wait, well I had all these meetings that I didn’t account for.What would you recommend? If you have thoughts to share please include them in the comments below.
