Sprint 5 planning

Greetings all –


Well, our Product Owner got the product backlog ready in time for the first sprint planning meeting, where we pick the product backlog items we’ll use for the sprint.  This planning meeting happened yesterday & went pretty smoothly, and everyone seems to feel pretty good about the product backlog items we’re taking on for this sprint.  Later today we’re doing the second planning meeting, where we put together the actual sprint backlog.


There was a bit of tension around how much internal/efficiency type work to do, as opposed to items that produce externally visible business value.  In my mind there always has to be a balance between the two – you can’t go overboard on one and starve the other.  One of the team members was pushing for more time to be spent on enhancing one of our tools, so as to save us time in this sprint and future sprints.  We wound up trying to time-box it to 5 days, but the team member (correctly) pointed out that this was insufficient for any meaningful progress on the tool, and pushed for more time.  The Product Owner let loose with some expletives, and wanted to know what bottom-line benefit these enhancements would bring.  This led to a good discussion about the full scope of enhancements to this tool, and the right priorities between them.  We wound up adding back a significant product backlog item (15 days worth) for the most urgent category of improvements to this tool, which everyone felt was about right.


We didn’t end up wrangling too much about the sprint goal.  There was some discussion around how much teeth it should have and there’s a tendency by some to try to turn it into a “contract” that spells out minimum criteria for success, such that failure to meet those criteria would lead to sprint termination.  However, we fortunately steered away from that and stuck to the “true” (in my mind at least) Scrum intent of the sprint goal, which is to be a theme for the sprint that guides prioritization if not all items can actually be completed during the sprint.


Thanks for reading, and stay tuned for more on sprint 5!




Comments (3)

  1. Glen says:

    You just freaked me out because we just finished our Sprint4 planning and pushed some items out to Sprint5. For a second I thought that we had already finalized Sprint5 (which can’t happen yet).
    <br>We usually try to set high level goals to help guide the developers during the Sprint when they enter &quot;Grey areas&quot; (does it contribute to the primary goal(s)?).
    <br>We do about 50/50 internal/external functionality. Since we have a server-based product, underlying enhancements can actually be considered ‘business’ when tied to the correct vision. It usually takes a number of sprints to chip away at any underlying enhancement that will actually bear fruit externally (speed, resources, etc). That is a hard sell to put those items into the backlog each sprint with little or no benefit until the end. . .