Splitting Story Points is a Smell…Stop it!

I was mostly sure we (as a community of practitioners) decided that splitting a story's points across multiple iterations was a bad practice a while ago, but I still see it being proposed or worse, actually happening.

What I feel is the biggest problem with story point splitting is the pattern of behavior associated with it. I often hear development team members complain that, if points aren't split, that they aren't "getting credit" for that portion of the work.

…seriously? …getting credit?! What is this, a college class?^[1] A story/feature is either done or not. No partial credit for half-baked features!

To be clear, I actually place the onus of this problem not on the development team, but on the individuals responsible for building and fostering the culture of that team. Why do the team members feel that partial credit should be recognized? Are the team's iterations really mini-death-marches? Are they being held to a velocity metric as a minimum? Is all the testing being left 'til the end?

In the end, the team should be working at a sustainable pace and should feel comfortable with a story not getting done by the end of the iteration.

Another problem is that splitting storie points artificially smoothes a team's velocity trend. This effectively masks any underlying problems that are causing the fluctuating velocity in the first place.

I also see a push to split storie points across iterations coming from a Dev-Manager, Scrum Master, Product Owner or some-such. Usually this comes from the desire to make some chart or table look better. It might be velocity "actuals", it could be projections of future done dates or even large standard deviations. It doesn't really matter what chart or metric it is; just making it look better on paper or Excel or whatever is not helping solve the problem that is making the chart or metric look bad in the first place.

What a team, including the leadership, should be focused on is not the beautification of reports, but on the removal of obstacles and variability in executing the work involved with delivering valuable, working software. Sometimes these charts and graphs can help, but not if we change them just to make them look good to others.

So, if anything you are running into on your team leads to someone saying "maybe we should/could just split the story points", stop there and dig deeper into the situation. I can promise you, you don't want to split the points :)

^[1] I first heard the comparison of "getting credit" for story points to college credit from Tim Wingfield.

Which is easier, Scrum or Lean?

The answer? Neither…it's unfortunate, but I see this question being asked more and more. Worse, I continue to see assertions that Lean is easier than Scrum.

Realistically, I don't even think this is a fair question. Comparing Lean and Scrum is apples to oranges. Lean, to me, is a set of values and principles that have some practices associated with them. Scrum, agnostic of agile, is simply a framework for work flow.

Some in the Lean camp seem to think Lean is easier to adopt because Scrum requires an entire organizational retooling to implement correctly, whereas Lean can just sit on top of your existing system.

To some extent, this is true. To adopt scrum correctly does require major organizational change. However, most places don't. When they "adopt" Scrum they simply just change some job titles and meeting names and send folks off to get certifications. That's pretty dang easy…of course, it's also not correct and doesn't really change anything (accept the Scrum Alliance's bottom line ;)

Lean claims, on the other hand, you can just lay it on top of what you currently do. Luckily most proponents of Lean would also say you should make your work visible. This alone can sometimes take an act of the gods, ousting some current tool that hides work and process. But, even if you do make the work visible, if you don't change anything it doesn't really matter does it? So we're at the same point as a poor Scrum adoption. In order for Lean to really work its magic you have to inspect and adapt. Further, if this is going to be sustained, you must also create a culture of continuous learning and improvement. Now, I dunno about you, but in most places I've been that constitutes major organizational change!

So, which is easier? Neither! Which is harder? Both! There are still no silver bullets. If you are desirous of getting better at delivering software, or integrating software holistically into your business, or creating a real organizational value stream you are likely faced with major organizational change. This change will be ideological and cultural, it will involve values and principles, and you will change methods and practices…and it will take a long time.

Good luck on your journey, there a lot of good people and good companies that can help you get to where you want to go, but it wont be easy. However, if you keep the right attitude, it can be fun!