Stens Scrummaster Blogg

One of the key elements in Agile and Scrum is the constant improvement of one self. Every day a little better might be a good paraphrasing of that element. I have always thought of velocity defined as the number of storypoints completed within a sprint, and it did not strike me what effect the subtle ways we treat and calculate velocity migt affect the performance of the team until I experienced the following conversation:
 
"OK, the sprint demo went really well yesterday morning!" Gary, the product owner said. "We had a very nice discussion and a record high turnup of users and colleagues from the business. Well done!" "Now, let's have a look at the user stories for sprint 32:".
 
It is thursday morning and the sprint planning of the next sprint has just started. The PO is preparing the team by going through the userstories he wants the team to do during the next sprint, but before that, he revisits the recently finished sprint and the user stories taken on in that sprint.
 
"I understand we finished six of the nine user stories the team took on, but these three here seems to have missed the Definition of Done, and did not make it. I'll have to move those back to Planned state."
 
"Yes, just keep them at the top of your list, and we'll complete them in this sprint!", Andrew said. Andrew is a senior technical expert but also the kind of guy that really understands the business and is a huge value to the team. 
 
"Well, I'm not sure I want you to do that, because these other two stories here, both medium sized, are very important to me and I really do not want you to delay starting them because you are finishing what you did not complete the last sprint. How big are they?", Gary said.
 
"Oh, what's left is really nothing! They barely missed deploy and test in the QA environment and we can do that in a few hours!", Andrew said. 
 
"OK, I guess we can prioritize them into the sprint. Do we change their size?", replied Gary. 
 
"No, we keep the size to medium and small as they already are." Fiona said. Fiona is a programmer, dedicated to the art of programming the way I've never seen someone be. Not the heavy lifter as Andrew, but still strong in her field and superior to Andrew when it comes to programming.
 
"I suggest you do change them!", I said. 
The quiet responce that lasted a few seconds, prompted me to continue:
"How would we know if we are taking on too much into this sprint if we know the estimates of some of the user stories are wrong?", I continued. 
 
I had been with the team as a scrum master for more than a year, and never really reflected on this practice before. What we did experience that had showed no particular improvement throughout the last year was a very unstable velocity. Accounting for holidays and a few small changes to the team, the velocity varied within +/- 50% between sprints. In addition to that, there seemed to be no or little focus on completing the user stories early. Most user stories were in progress most of the sprint and was finished the last few days before sprint end. 
 
"Yes, but if we re-estimate the unfinished user stories, how are the work we did on them accounted for?", Andrew said. "If we do that, then the average velocity will be lower!", Fiona added, and continued: "How can the PO plan when the average velocity is wrong?". Andrew: "- And I am not sure the project management really would appreciate the lower velocity indicating that we are lagging even more behind so close to the first production release!".
 
I sensed some real agitation and that the room temperature was rising. "Well," I replied, "The team velocity is really none of the project managements business. What we need to focus on is to get the velocity stable, so that we can better plan for the sprints. We are not planning for 5 sprints, we are planning for one. Therefore the average velocity has no meaning to us."
 
"Yeah, but we've always done it this way. Changing it now would make us inconsistent." Andrew replied.
 
"Do we not have to change things to improve? Let's not discuss this further at this point. This is a retrospective issue and we are in the sprint planning meeting. We will get back to this in two weeks." I replied.
 
Gary continued his walkthrough of the list, placing the unfinished user stories just after the two important ones. In detailed planning, the team added both the high priority user stories and the finishing of the uncomplete ones but the priority was kept and the team started off working on the high priority user stories, the first couple of days.
 
I have a feeling that giving in the first time, I still had planted a seed in the team members. They might think they won the first round, but my idea is to help the team members seeing this themselves. 
 
During this conversation I realised that the practice of bleeding userstories over into the next sprint was one of the reasons the team had very little energy on changing the way they worked and that the team velocity was so unstable. At some level, they had no need to focus on completing the userstories within the sprint, as they would be 'rewarded' for the work with storypoints in the next sprint. This way, the 10 storypoints they missed in sprint X would be added to sprint X+1 making the velocity jump from 15 to 35 between two consecutive sprints.
 
By continuing this practice they are missing the pain of not having their effort appreciated through velocity - which is a major driving force to change.