How getting caught up in the accounting can make us miss the point
My cell phone rang and it was my Agile coaching compadre on the other end of the line, exasperated. Uh oh, time for an Agile intervention.
He had a team that took on 10 points of user stories in a sprint, but only finished 3 points. Now they were planning for the second sprint, and they were starting in a hole with work to complete on the 7 unfinished story points, plus another 10 points of work they were taking. They were trying to keep their average velocity at 10 points per sprint. I asked him what they were going to do about the credit for the 7 story points that spanned the sprints?
"They're going to get credit for them in sprint 2, since that's when they completed the work." Well, he couldn't give them credit for the points in sprint 1, since they weren't completed. That was the right answer there. I asked how much of the work was left over for the stories. "About 10% left, all testing" was his answer. Hmmm…OK. Something was bothering me about that. The majority of the work on these points was done in sprint 1, but they weren't completed in sprint 1, so the credit couldn't go there. But to get full credit for 7 story points in sprint 2, when only 10% of the work had to be completed, wasn't striking me as kosher either. What about partial credit in each sprint…90% credit (6.3 points) in sprint 1, and 10% credit (0.7 points) in sprint 2? Well that seemed like ridiculous mathematical gymnastics, and besides, it would send the wrong message to the team: that it's OK to NOT finish work in a sprint.
We continued debating the issue and trying to decide where the points should go. They had to go somewhere, didn't they? And then it hit me.
Those 7 points go nowhere.
Those 7 points go nowhere.
No credit. But they DO have to complete the work. "Well, that's an answer that everyone will hate" was his response. They probably will, but its tough love for the Agile team. And here is why I think it's the right thing to do.
What are we measuring with story points and level of effort? First off, it's NOT "time tracking." It's not meant to be a measure of how the team spent their time. What we are measuring is business value delivered. Stories are worth nothing to the business if they are not completed. We want teams to start a sprint entering into a commitment with the Product Owner that they are taking on work, and will finish it in the sprint. Of course, there are times during a sprint when work takes longer than expected and teams can't finish everything they committed to, but that's when the Scrum Master facilitates communication with the Product Owner to move the lowest priority not started items back to the product backlog, ensuring that whatever stays in the sprint can get to "done." I covered this in a previous blog post.
You honor the commitment, but story point credit and velocity has predictive value in measuring how much work the team starts and completes. Since this was not the case with this work, no credit is given. Would everyone (team, Scrum Master, Product Owner) hate this solution? Sure, but it makes for a great retrospective topic, and a lesson learned for the future.
So how do you, as a Scrum Master or Agile team lead, avoid having this happen in your teams? Here are a couple of tips:
What are we measuring with story points and level of effort? First off, it's NOT "time tracking." It's not meant to be a measure of how the team spent their time. What we are measuring is business value delivered. Stories are worth nothing to the business if they are not completed. We want teams to start a sprint entering into a commitment with the Product Owner that they are taking on work, and will finish it in the sprint. Of course, there are times during a sprint when work takes longer than expected and teams can't finish everything they committed to, but that's when the Scrum Master facilitates communication with the Product Owner to move the lowest priority not started items back to the product backlog, ensuring that whatever stays in the sprint can get to "done." I covered this in a previous blog post.
You honor the commitment, but story point credit and velocity has predictive value in measuring how much work the team starts and completes. Since this was not the case with this work, no credit is given. Would everyone (team, Scrum Master, Product Owner) hate this solution? Sure, but it makes for a great retrospective topic, and a lesson learned for the future.
So how do you, as a Scrum Master or Agile team lead, avoid having this happen in your teams? Here are a couple of tips:
- Use solid velocity measurements in sound planning: Scrum Masters should use velocity as a rolling average, not a single number, and in concert with good capacity planning (vacations, holidays, other commitments, other drag factors) help keep the team from "biting off more than they can chew" in their commitment in sprint planning. This is precisely why I feel you don't get credit for partially completed stories at all…it provides no predictive value.
- Minimize WIP: The fewer number of stories a team has in flight at any one time, the greater their flexibility to adjust and move not started stories around without having wasted effort and having to unwind code from the codebase.
- Inspect and adapt daily: No matter what, keep the daily standup sacrosanct and effective. It remains the team and Scrum Master's primary channel for surfacing and mitigating potential problems before they become real issues.
- Practice "tough love" servant leadership: Remember, a Scrum Master is not a manager of the team, they are the coach and protector of the process framework. The coach does not take the field; he/she observes, advises, supports, and puts the team in a position to succeed. And by practicing tough love like in the example here, a Scrum Master helps the team, and him/her self, learn a valuable lesson from a mistake they are unlikely to repeat in the future.
"What we are measuring is business value delivered." ... No. Its Effort. Not the same.
ReplyDeleteYou can put in a hell of effort without ever finishing. That is why you are wrong. Would you grant credit to a marathon runner if he/she quits in the last mile? Surely not, even if the effort was in. That is why you are wrong. The story point must measure the business value delivered.
DeleteCorrect, the whole reason for using story points is to get away from estimating in terms of effort (hours, days, etc). The customer cares about business value, not your effort. Otherwise you could just bill them for your time without delivering any usable software.
DeleteHours, days is a measure of time and not effort. This blog entry refers to story points and they describe effort and not business value. There could be one (relatively) simple user story of few story points which gives enormous value to a customer (like e.g. SMS service in GSM network vs. data services with all their adaptation functions - don't confuse with GPRS, LTE and the like).
DeleteIt IS effort, I agree...but effort expended delivering business value. In other words, it's not just measuring activity. That's why I don't advocate pointing bugs, for example. "Effort" squashing bugs is work the team is doing, but it's not delivering business value. And before someone replies "isn't delivering defect-free softwar valuable to the business?" I would say yes, it is...the first time around. Fixing defects is rework, which is a lean process waste. It's bandwidth the PO can't spend on new development because it's being spent on fixing defects introduced in previous development.
DeleteAll of which is to say, again...Points for velocity is worthwhile as a predictive measure of how much a team can accomplish to develop and deliver quality product...fixing old work robs from that time.
To my mind story points is indeed a measure of effort (NOT time) and not business value. The team estimates story points against how easy or difficult they think the story will be to implement, not how much worth it has. Business value is a something different, and ROI can be calculated by dividing the business value by the effort.
ReplyDeleteTotally agree. Business value measure is different from effort. I like to think of team effort/points as capital a PO has to spend in a timebox. Business value helps the PO determine where it's the wisest to spend that capital.
DeleteI agree the story points is a measure of effort not business value. A story can have high value, and can take a low level of effort to complete. Likewise, a story may have a low to mid level business value, but with high effort.
ReplyDeleteIf story points represented business value, then if teams only worked on stories with high points because of their desire to deliver higher value stories, but those stories took little effort to complete, then teams would either have (1) really high velocities or (2) would probably finish sprints earlier than anticipated. Higher business value does not equate higher effort, and neither does the inverse. Thus, that's why we refer to story point estimations as "relative sizing". We're estimating the effort to complete a story relative to other stories, and not the business value relative to the value of other stories. That makes no sense at all.
And with the comment above, "The customer cares about business value, and not your effort.", while that's true, customers probably care less even more about story points.
Pffft... so wrong. Just defer the points to the next sprint. They get credit for them then. The average velocity comes out eventually.
ReplyDeleteagree
DeleteThis comment has been removed by the author.
DeleteAgree that it comes out in the wash, and a rolling average over time is the best way to look at velocity...the point in this post is that if you do that and gloss over unfinished carryover work in the process, it can send the wrong message to a team that the sprint timebox doesn't have much meaning with respect to commitment...it becomes just a box on the calendar, and this can cause teams to increasingly diminish what their "commitment" to a sprint goal means (if they're just going to get the "credit" regardless). Leads to bad behavior, IMO.
DeleteThis comment has been removed by the author.
ReplyDeleteIn my opinion, points should go to the sprint where the story was finished. Saying that "the customer cares about business value, and not your effort" is an invalid argument, because when the team finish the story in the second sprint, they are delivering business value.
ReplyDeleteSimply trashing these story points makes harder for the team to estimate their velocity as explained here: http://codingopen.blogspot.com/2016/06/where-to-put-story-points-of-partially.html
...And I think this approach is fine, if you're not concerned with a sprint commitment meaning anything, sprint to sprint. If you're working over a multi-sprint timeline and don't need to have working product ready at the end of every sprint. If you do, again...I think you send the wrong message to the team. In my experience, adopting Agile is as much or more a culture change as it is process change.
Deletealthough it is an old article, it has a current value for us. We also run into the situation occasionally to not have finished UserStories in one sprint. As Scrum Master I decided that we take the whole story to the next sprint including the effort estimation (Story Points). For us the story points are not a measure of business value, only a relative value to compare work. While we have no problem that we carry over story points from one sprint to the next, and having a velocity based on rolling average of story points completed over say 3-5 sprints, we still are unhappy that we did not complete the story in the first place. That is the actual problem to tackle i believe - not "how do i take over stories properly"
ReplyDeleteThanks for your comment. And you're getting to the point of the entire post. This wasn't meant to suggest a Scrum Master accounting methodology...it was meant to drive a point home to a team to respect the sprint commitment they make, and not have this happen again. If we do that, we make velocity (even measured as a rolling average) more valuable as a measure for evidence-based planning, especially in situations where we don't know exactly when we'll have or need to have a block of functionality ready for release...but we need to stay prepared for it every sprint.
ReplyDelete