Butterfly effect of one sprint planning action

I recently came across a situation where one of the scrum teams during their sprint planning sessions while recommitting a story (not completed during the previous sprint) accepted it to sprint backlog without re-estimating it for the level of effort and amount of work left to meet the acceptance criteria. I asked the scrum master and product owner as to what was the reason for that. Scrum master mentioned that the management wants to give credit to the team for doing the work in the previous sprint despite the work not being completed. Product Owner’s take was that team can not with great level of certainty identify how many story points worth of work has been completed from the originally allocated estimate so instead of re-estimating the size of the story, the team just accepts the size based on original estimate. This discussion had another dimension added to when I heard from the IT manager who oversaw the team’s work and according to her, since the team has completed for example three points worth of work in the previous sprint out of the originally estimated eight points, it was unfair for the team to not count those three story points towards the velocity of this sprint in which the story is being re-committed.?

What are your initial thoughts based on the information provided so far? I would love to know what you’re thinking but hold your thoughts and help me get through this before sharing your perspective. While we can reference scrum guide by virtue of which all incomplete work that doesn’t meet the definition of done as set forth in form of acceptance criteria goes back to backlog to be considered again, it would be unfair to not present a big picture context why estimating work to be added to sprint backlog should be based on level of effort required to complete it based on what we know today and where we are today. For this purpose, let’s consider three reasons why teams should consider re-sizing stories despite being rolled over. I will use a five point story for this example where based on the last refinement session, team believes that two points worth of work has been completed at best and there is still three points worth of work to be completed but the team doesn’t want to lose two velocity points so they will re-commit a five point story.

Team carrying over a story due to incomplete work without the impact of any external dependency allows us to dig deeper into causes that need attention from a troubleshooting perspective. Retrospective is the perfect place to start that conversation and scrum master should use open ended questions like “Why did we not deliver this story?” Or “What was our roadblock for not delivering this commitment?”. When a team continues to roll over user stories from sprint to sprint, that usually means that there is an opportunity for the team to sharpen their refinement axe and work on more outcome focused refinement. Scrum Master and a coach who is external to the team can help with this. This involves inspecting the acceptance criteria for the story with a fine comb. Acceptance criteria for stories should be stated in bullet format in a way that each bullet can be answered with either a yes or a no. This makes it easier for product owner and team to answer the question at the time of review “Does the work done on this story meet the definition of done?”. Another action that can be taken by the scrum master is to work with the team to take inventory of stories rolled over in last 5 sprints in terms of story points for those items. If a team is having issues continuously finishing eight pointers in a sprint then it is prudent to further break down any eight point story to five pointers. Limiting team’s commitment to five point stories will force the team into thinking about this sprint over sprint behavior. A good scrum master will use this during refinement and planning sessions to coach, train and motivate the team to improve their refinement, acceptance criteria and communication on daily work to impact growth. Enabling the teams to self discover by virtue of their failures and identify opportunity areas to work on with help is a lesson that will never be forgotten in the long run.

There is another benefit to forcibly adopt re-sizing of stories even when that means not giving the teams credit for the two points of work already completed since the story’s work did not meet definition of done. When the team considers a User Story X from Sprint 1 which was originally a five pointer and upon consideration, team agrees that two points worth of work has been completed and today there is only three points worth of work left and assigns it three points during sprint planning, the team in turn is absorbing the loss of two story points worth of velocity for the sake of long term gain. It should hurt the team to not get credit for the work done and this should make the team and leadership work together with a coach to get back to the drawing board to once again work on continuous planning which includes refinement on top of the list. Leadership needs to endorse such actions for any leader who has at his or her heart long term growth of the organization and will sacrifice short term gain of two story points sprint over sprint for three iterations to ensure that team continuously improves its refinement, estimation and planning practices. This lays a solid foundation for a predictable team which brings me to my next point leading into how one team adopting a best practice can turn into an organizational culture.

Many organizations and programs within organizations use dashboards, tableau reports, excel sheets, Sharepoint tables to inspect progress of teams down to hours and minutes. By re-sizing the story for Sprint 2 Planning, by sacrificing those two story points worth of work done (not completed per definition of done), team is sending a message to leadership that if this team will adopt better software development practices, then it needs to be done wholeheartedly and not just in bits and pieces. Leadership will have to for the time being put away their love affair with numbers on hold and embrace a more broader cultural impact of this one practice. When this team completes five sprints without having to roll over any stories and delivering most of the work barring any external dependencies, word will get out. Leadership will also want to know what is the reason for this turnaround and when leadership has eyeballs on this matter that means, this practice is about to be shared with other teams in the program. This creates a wave of change by virtue of one small action; re-sizing of stories at sprint planning based on the work needed to be done. This is how cultural changes take roots when leadership owns difficult decisions by not running after numbers alone but by considering the bigger picture of a change in form of incremental improvement over time using behavioral tweaks. It is just not enough for leadership to understand and embrace the concept of change but need of the hour is for leadership to exhibit fearlessness by considering strategic impact of that change and how small individual actions can in fact anchor long term change of organizational culture.

The above example is just one instance of how small actions with seemingly negative short term impact on team morale and motivation in fact have deeper long term positive effect?on broader collective improvement. It is about finding different ways to make teams more predictable and organizations more nimble in an age where agility is not just a software development framework but a way of life for long term market dominance. It is not just the different tools and practices in play that make agility possible in the long run, but the very mindset of leaders trickled down to middle layer management and permeated down to the knowledge workers that fosters a culture of getting comfortable with change thus resulting in relentless improvement year over year.?

What are your thoughts on this??

Where does your organization stand on culture of change comfort?

What mindset challenges do you have in place that your teams can work through?

Let’s talk !!!