Friday, 12 January 2018

Sprint Planning - Velocity Planning?


Towards the end of our sprint planning session today we were in a position of committing to just over our current velocity. Our Scrum Master rightly wanted to check if the team felt comfortable with doing that, and was met with a resounding No. We have recently lost a developer from the team, and therefore felt uneasy about committing to more than, or equal to, our current velocity.

The stance back from our Product Owner was however that we should be committing to velocity, as recent training courses they had attended stated this was the thing to do, and if we don't do this, what is the point in having that statistic.

This led to a tricky stand off between the PO and the development team.

Our PO was absolutely of the mind that we should be planning to velocity. Of course, if we hadn't lost a developer then I'm sure this would have been accepted, but the development team was stating their unease in doing this, and wanted to commit to slightly lower than velocity, given the reduced capacity and the high complexity of the user stories in scope. Plus, we had a 3 day time boxed spike and 2 bugs (not included in our velocity) to contend with.

This has made me want to learn more about velocity planning, and has led me to two points:

  1. Should you use velocity to plan a sprint if the team has decreased in size, and
  2. Velocity v capacity planning

So, point 1. From what I have read, velocity planning is an excellent gauge of what a team can achieve in a sprint, if that team is mature and has a constant team size. As Mountain Goat software states:

Velocity-driven sprint planning is based on the premise that the amount of work a team will do in the coming sprint is roughly equal to what they’ve done in prior sprints. This is a very valid premise.
This does assume, of course, things such as a constant team size, the team is working on similar work from sprint to sprint, consistent sprint lengths, and so on. 

And as this article on Scrum Alliance states:

Velocity relies on team consistency in order to be most valuable. If your agile team changes, use common sense in planning future iterations. If 20% of your team is unavailable for a couple iterations, then reduce planned velocity by 20% or so. 

So these posts indicate the development team was correct to push back on using velocity planning in this instance. I can certainly see the benefit of using velocity planning in the future, but only once the team has re-stabilised and gone through several sprints (4-5 is the recommended).

Onto point 2, velocity v capacity planning.

Let's get the easy bit out of the way: you can only implement velocity planning if you have a team that has been around long enough to do that with. A worry, though, with velocity planning is that the development team can become "story point accountants". Capacity planning makes sense as you can build your sprint to who is available, but doesn't factor in complexity as well.

This article on Software Engineering Stack Exchange tackles the velocity v capacity planning question. I like the takeaway:

My advice would be to use your story-point velocity that you have established to determine which stories to take on, and then build out the true capacity for the upcoming sprint based on resource availability.

That makes sense, right?

Aside from the two points above, one angle that I hadn't considered was the Sprint Goal. If this had been set up front in the planning session, perhaps this would have given our PO more buy in into over committing, as we may have included the story that we moved out of the sprint if it was an integral part of the goal?

Oh, and in case you wanted to know what happened in our case, the agreement was made to commit to just under velocity, with the next story to pull in agreed to be the one that was not committed to. So the development team's view was taken over the PO.

From my research as illustrated above, I'm pleased that it was.

Saturday, 2 December 2017

DevOps at Sprint Planning

Today marked a real success for the team as we start to make our way to a more DevOps way of working. Our "DevOps Resource" (read representative of ISS / Sys Admin), sat in with us at our sprint planning meeting.

This allows Shaun to gain the context of each user story that we were going to commit to and promotes buy in, involvement and feeling a part of what the development team is doing.

Importantly, as this is sprint planning, Shaun has an upfront view of these stories, so we will avoid the usual rigmarole of emailing / Skyping as and when we need ISS involvement and the inevitable frustration that arises when a) we can't get hold of them, or b) they do not action our request quickly enough.

As we embark on the latest sprint, we're seeing these ISS tasks either get completed by the first day, or soon after. This has resulted in an improved relationship between the two parties and I believe a sense of empowerment for Shaun.



Long may that continue!

Wednesday, 29 November 2017

Post #1

First post

Here's the very first post to my new blog. I am a lead engineer, and aim to post my thoughts and adventures from my day to day working life.

Check back soon to see what's been going on!