Today, I interviewed a developer/team lead who had a very similar first experience with Scrum. Not very surprisingly, it matched my own so I thought I would share. The terminology sucks Two years ago, when Scrum was first proposed, I remember I hated the terminology. Sprint? Backlog? Scrum? Story Points?. It is like a mixture between a sport and fantasy novel. Back then, I liked terms like requirements and project plans. »
One interesting observation I have seen regarding Scrum at Rackspace Apps deals with task breakdowns. Breaking down a story from the product backlog is an important step to create the sprint backlog#Sprint_backlog). Breaking things down into smaller pieces is going to increase estimation accuracy, as well as help the team understand all the different parts of a story. But tasks don’t mean anything. The story is the functional piece of software the product owner requires, not any individual task. »
The project managers, and some of my team leads, have started throwing out the idea of Kanban instead of Scrum. Really, they are wanting to start with Scrumban, where they ease into Kanban and as Rex likes to say, “kick the ends out of Scrum”. One of my teams has started playing with it. Here are my initial thoughts. I don’t feel bad about pushing important things into a sprint that are a high priority. »
Over the past few months, I have been working a lot on release planning for my teams. Not only have I seen the light on its importance, but it has also helped me realize problems with my own prioritization. Each time I change my release roadmap based on additions/modifications to the backlog, I realize how hard planning for the future is. My solution, the Volatility Factor. Here is the scenario. You have a team with a velocity of 15. »
Last week, Rex came to me asking if the Webmail Apps team could have their sprint planning at a park here in Blacksburg. I thought it was a great idea, and yesterday we had an awesome morning of planning, followed by some grilling. Lately, the project management team has been pushing a lot more of these type outings. In my opinion, it stems from the fact that developers hate meetings. Even though sprint planning meetings are needed and important, teams hate sitting in some conference room for hours. »
I bought a house! I am moving into that house Product backlogs »
Our company blog, Rackspace Email & App’s blog, just had a post from Rex. It’s all about Scrum here at Rackspace (yes, I no longer respond to Mailtrust since our recent name change). I encourage you all to follow the Rackspace Email and Apps blog (yes, shameless self promotion) for any tips from our project management team. Rex is the PM for all my software development teams and all my scrum posts are either stolen or inspired by interactions with him and those teams. »
Being a product owner is hard. Making sure you achieve the proper balance of tasks across different stake holders in a product isn’t easy. Support and operations need certain enhancements that make servicing the customer easier, while the business needs to advance with new features as well, and the designer wants to make the user twice as happy by tweaking a few things. All good things, that require good prioritization in order to make a successful product. »
One of the nice things about Scrum is the lack of rules. There aren’t a lot. And the rules that are given, should be changed over time. Scrum, like development, is an iterative process of continual improvement. A very important part of the Scrum process is sprint length. If you’re thinking I am going to tell you an ideal sprint length, you are wrong. My Scrum tip of the day is just to make sure you’re adjusting sprint length based on many different factors. »
Estimating is hard. Developers, at least in my experience, are notorious for making their lives harder and underestimating tasks. No matter how often you tell them to be realistic, it doesn’t happen. There are a few things that can be done to mitigate this. Be realistic about the hours actually focused on development. Many team members, especially team leads, spend a lot of time doing other tasks outside of a sprint. »