With my current gig, we’ve started a new project lately; and like any new project with a scrum team of new people, you have to work together to define a set of working agreements, and definitions.
In my experience, most agreements are established fairly naturally. For example : What time do we meet for stand-ups everyday? If you have a remote team – How do you do story hand-offs? Even larger questions that evolve over time, seem to happen naturally, such as : What do we value in code style? Or, what does well styled code mean for us as a team?
With this latest group, I’ve run into some questions whose answers don’t occur as naturally. These questions emitted from the idea of – how do you do Scrum itself?
Scrum is admittedly, by many, including it’s founders such as Ken Schwaber*, a framework, rather than a process; and a simple framework at that; So questions like how will Scrum work for us? – Are much less clear, and convoluted questions.
One debacle was over an idea that the group thought was fairly centralized, and commonly understood by the group; However, when attending sprint planning for the first time, it became apparent that there wasn’t a common understanding. What was this?
What the hell are story points anyway? A relative, abstract number describing complexity of a story? A relative, abstract number describing effort of a story? These two definitions, in our case, were brought to the table. When you zoom into the scope of a sprint, or two; These two definitions at the surface, appear to yield vastly different results.
If a story comes into our sprint that seems very much like a story that the team has worked in the past, and we decide that story points are effort; We may rank the story a 2; Considering we may recall that the previous comparable story was ranked a 3. The story draws some strong correlations, thus the team may say that this story requires less effort due to existing problem domain familiarity. I generally like to think of points this way.
Some may say that measuring effort sounds an awful lot like measuring a correlation between points, and hours taken; and I admit that when I usually rank something a 3, I’m thinking, “3. Yeah, that’s probably about a developer sprint.”, but understand that that is very different from saying; “Yup, this will take a week.” The latter is certainly something I would never be humbled to say to a product owner, for both his benefit, and mine.
The point is, that in my opinion, you are creating an abstraction, and indirection from time to this seemingly arbitrary number; not a direct correlation – which I agree would be a bad thing like many have stated. If it’s a direct correlation, skip the bullshit, and just measure in hours. However, points will protect both you, and the product owner from the fallacy of pretending to know how long a problem will take to solve. Points in this sense, are a team generated point in space that’s kept generally consistent through relative intuition.
Coming back to the example; If the story was ranked in terms of complexity, we may rank the story a 3 based on relative complexity, as complexity of the story is seemingly, relatively same to the complexity of the previous story worked. This angle correlates points with the complexity of the system being worked, in contrast to correlating points with the effort of implementing a complex system.
One benefit from doing things this way is that it makes no assumptions about how strongly previous experience will correlate with the current problem; even if intuition says it is obvious. It seems safe in this way. Even if intuition screams similarity, even to the extent of,
“Wow, I’ve pretty much implemented this same feature with same set of tools, and environments on an old project”
countless variables can yield different outcomes; including team makeup. In scrum, since all work is team work, no perfect assumption can be made on how the complexity of a feature is analyzed. Maybe a team member conceptualizes the feature into fruition in a much simpler way than was done previously?
My guess at the end of the day, is that it doesn’t really matter which philosophy your team takes, as long as the philosophy stays consistent. That’s really the beauty of points as an abstraction. At the end of the day, points are used to measure time, regardless of your method of generating points. If your method stays consistent, and points become fine tuned, and convergent to features produced over time, as they should – the product owner is able to use burn-downs to measure time-to-market.
Consistency is key friends..
* – By the way, Ken did a tech talk at Google that I really really enjoy, that I tend to reference often. I highly encourage you to check it out