LevelTen's Scrum and Agile Challenges in 2010
LevelTen has been practicing Scrum, mixed with other agile practices, for about a year and a half now. While we have solved plenty of challenges this past year on figuring out how to use the Scrum framework to fit our company, we still have a lot to learn on how to be truly agile. The challenges we face were really brought to light during Mike Cohn's ScrumMaster Certification course I took early this week. I jotted down several ideas from Mike and noted the challenges that I hope we are able to overcome this year. Below is a summary.
Roles
- Scrum has 3 roles - the ScrumMaster, Product Owner, and the Team. While we've nailed down the ScrumMaster role (that's me), we do not have a strict assignment for Product Owner(s). Our Account Managers have loosely played this role, but they haven't been trained in the Scrum responsibilities that are required. Kayla and I have been acting as intermediaries, taking on tasks such as story creation, backlog prioritizing, etc., and this year I hope to transition this knowledge and responsibility to a true Product Owner (or two).
- Mike noted that ScrumMaster responsibilities not only include removing impediments, but improving productivity in any way possible. While I knew the basic responsibilities, I never really thought of it like he said - doing anything possible to make the team better. Mike's metaphors for a ScrumMaster were being a "servant leader" and a "sheepdog." (Dustin thinks this must mean that he grows the wool.)
Meetings
- The Daily Scrum meeting is for synchronizing efforts, not a status update for the ScrumMaster. I've known this, but Mike made a good point by saying as time goes by, the ScrumMaster should not have to continue asking each team member the three questions. I took his advice and now the team is leading the meeting itself by passing around an Ugly Doll to designate whose turn it is to speak.
- Mike reinforced that the purpose of the Sprint Planning meeting is to arrive at a commitment to a sprint goal. The goal is NOT to break stories into tasks and hours. While LevelTen always makes sure the team commits to the sprint backlog, it's not something we do as we go along in the meeting. Instead of pulling tasks over until we reach our capacity, our goal should be to pull tasks over until we think it is "enough" for us to complete.
- "The Product Owner prioritizes. The Team sequences." Mike Cohn noted that the TEAM defines the sprint goal, or the amount of backlog they want to take on. I would like to give this control back to the team, rather than relying on capacity.
- Story estimating, or Planning Poker, should not happen in the Sprint Planning meeting. Estimates will help the Product Owner prioritize - he needs to know the cost of something first. I'd like for LevelTen to start having regular backlog grooming meetings each sprint in order to plan for future sprints.
- Scrum tasks should not be assigned in sprint planning. We were true to this point when we first started, although we found it difficult to commit to the backlog without knowing the commitments of individuals because of our varying billable hour allotments and various skill sets. Mike recommended a team find one feasible path to complete the work, but this does not mean assigning names to tasks in the planning meeting. I would like to go back to having no name assignments, but we'll need to figure out a path each time.
Stories and Tasks
- Backlog items should be "potentially shippable increments of product". I learned these should be business value related only, more like "features" rather than things that need to get done. The backlog items we have created in the past included "Design Comps," "Wireframes," or even "Drupal Install." While this has worked as far as getting things done, our backlog has not been focused on business value, and that's really what our business is all about, creating value for our clients.
- User stories do not have to necessarily be something a user "wants." If it's required, the story could be: "As a user, I am required to..."
- An ideal task is from 6-8 hours. In the past, our tasks have varied across the board with the majority being 1 and 2 hr tasks. It's no surprise that our board is chaotic sometimes with the overwhelming number of tasks. I would like to find a solution for creating bigger size tasks, but as we have an awesome development framework, the majority of tasks just don't take that long.
Release Planning
- One of the most challenging things we are facing right now is how to implement Release Plans for multiple clients who make up our one sprint backlog. The challenge arises in that a Release Plan is based on story point velocity. While we have a story point velocity for our team, it's hard to say how many story points we can complete per client, per sprint. Mike recommended that we allocate a certain number of points for each client, but allow a buffer in the plan so that we can take new projects/requests into account.
