In my last post, I described that our team routinely overestimates the amount of work it can finish in a sprint. The amount of this overestimation is quite high at times - sometimes we only finish two-thirds of what we initially plan. So how can we get our estimation better? I think there are two sources of estimation error: one is how many hours per day you actually have to apply to sprint tasks; the other is how many hours it will take you to actually finish something.
I think we’re going to enter into an interesting discussion with our product owners where they would like to propose moving away from a fixed-length (in time) iteration model to a fixed feature set model. The claim is that it is too hard to maintain a release roadmap when the set of features that comes out of a sprint is fluid. [Sidebar: our sprint teams routinely overestimate how much we can accomplish, so items are always falling off the end of our sprints.
When you have two or more sprint teams dedicated to a product, I think there’s an opportunity to stagger their efforts in the following way. Let’s track a user story through two sprints. In the first sprint, the prototyping sprint, design, UX, and development cooperate to put together a working proposal for a user story. At the sprint review, if possible, the whole user story will be complete, where design, UX, and implementation are all consistent.
After planning, we dive right in to having daily scrums. We’ve gotten these to be pretty efficient (today we had a 10-person scrum finish in around 8 minutes). One key thing is starting on time–we charge people $1 if they are late to the scrum, and no one (not even the scrum master) is exempt. When we get enough saved up, we make a donation to charity (there was a thought that this should go to buy donuts for the team, but that felt a little like rewarding ourselves for being late).
If you’ll recall from my earlier post about pre-planning, we enter into our sprint planning meetings with a stack of user stories written on large index cards. The first thing we ask everyone to compute is the number of hours they have available for the sprint, starting with number of working days, subtracting out holidays/vacation, and then using a general availability of hours per day of productivity. We’ve tended to use 6 hours per day per developer, although not everyone uses that rate, particularly tech leads and team members doing double-duty as scrum masters.
For a little while we experimented with truly cross-functional teams, where we had copywriters, graphic designers, UX architects, frontend developers, backend developers, and QA folks all on the same team. I thought this was great, and our planning meeting was very interactive, as everyone had things to work on for new features. There was constant collaboration throughout the sprint: design/frontend, frontend/backend, product owner/QA/UX, etc. As a developer, this was great. We had instant access to team members from the other disciplines, able to brainstorm about how a feature should work and getting questions answered quickly.
I think the way I’ll go about my scrum discussion is to go through the order of battle for one of our sprints, at least from my point of view as a software engineer/tech lead. We usually kick off a sprint with a pre-planning session that happens before the formal Sprint planning session. In this session, we walk through a list of asks from our product team (who come prepared with a big whopping list of them off the product backlog), put LOE (level of effort) estimates on them, and then help distribute them across the multiple scrum teams we have dedicated to the product.
Sorry for the pause in posting–I have been a member of our support scrum team at work for the past six weeks or so, and the ensuing insanity in my work day left me too tired to post anything here. I think what I will do is pick up with a review of some of the scrum practices we’re using, what works, and what doesn’t, probably moving through some of the same sequences of areas as the somewhat infamous (at least around here) “Swedish Scrum” article, Scrum and XP from the Trenches Hope you’ll enjoy the discussion.
Needed to whip up some automated sanity testing of a webapp, and Cactus seems to have a somewhat steep learning curve. Eventually, yes, this might be the way to go, because we should be able to integrate it nicely with Maven and CruiseControl, but I needed something quick. In particular, I needed to check whether a certain number of images were showing up in a portion of a JSP-generated page.
We have a web project that gets built using Maven; it was relatively simple to get this running under CruiseControl since CC has pretty good Maven2 support. However, we also wanted to have a successful build actually deployed to a Tomcat somewhere at a known location so that people could always check out the latest version. I played around with various maven plugins for working with Tomcat, but had a really hard time getting them to work properly.