Authored by Preetam De, a blogagility.com contributing author.
In the last few days several people have asked me a question about stretched targets on Scrum sprints – not sure if it was a co-incidence or an ongoing vibe. So I will take a moment to explain it.
This article will not revisit the negative consequences in detail of having a stretch target. I will assume the obvious with a quick recap, so I can focus on the solution in detail rather than discussing the problem.
Quick Recap – Why do we think we need it?
- When we feel the need to manage a person rather than the work they do.
- When we focus on Efficiency over Effectiveness.
- When we focus more on tools and practices more than the principles behind them.
- To impress stakeholders they need everything “right now”
- To impress authority by over-estimating our capabilities
- When we assume – “What happened last sprint won’t happen again”
- When we don’t trust a team member and say “We need to keep them busy”
How can we avoid Stretch Targets?
A) By focusing on the flow of work that matches the business need
This part covers the solution to 1, 2 and 7 mentioned above. It’s a topic which majority may not find an issue with. It’s so subtle yet so powerful that we assume “That can’t be a solution ! It’s too simple to be a solution”. Yes, it is simple and that’s why our urge to over complicate simple things gets on our own ways.
A good example of flow of work
In a development team, either Scrum or Kanban, we have a known trend of monitoring work. We plan the work – then implement it – then we test it – then we release it. Testing is always a part of implementation but majority still assumes it’s a separate practice that has to happen and hence you will see a swimlane similar to “In Testing”. Separate topic perhaps.
On this above setup, we see a board with columns as many as 10 or more on some cases. Like – To Do, Re-opened, In Progress, In Code Review, Ready to Merge, Ready to Test, In Testing, In UAT, Ready for Production & In Production.
This – is what we will always see when we are focusing too much on who is doing it and getting paid instead of what are the value of tracking them. As a business, do we even give a shit if it is being code reviewed? That’s a habit, a practice, a step which ensures quality of code.. and in an insignificant information for anyone outside the development teams.
“But we as developers need to track it for ourselves” – yes, true. But it is a second nature that you should be doing anyway. You wake up every morning and brush your teeth, it’s a habit. You don’t have to talk about it nor should I care. Well, unless I am your dentist 😉
Truth is, developers do it to show the state of the progress as they fear some might think they are slacking. When this becomes a norm in any development team, stretch target becomes a norm too.
It’s normal to see on the last few sprint days, there is nothing in ‘To Do’ or ‘In Progress’ – so we assume that the developers are doing fuckall and getting paid for free.
Therefore, to “keep them busy” we add a stretch target in the planning session to utilise the “Resource” efficiently if needed. Result: Always a sprint where we never manage to finish the committed work and our moral goes down. We know it will bring zero value in our sprint, as anything we start that late can’t be finished by the end of the sprint.
| Planned | In Progress | Ready For Release| Released |
Solution is simple as above, create a board to support the tracking of effectiveness towards the business. Use the remaining timebox to work on Spikes/Investigative work that may help refining the backlog rather than starting a new work.
B) By accepting the fact – “History repeats itself” – more often than we think
How many times have we said “It happened that one time and it will not happen again”. Then saw it happening again in few weeks or even days. Truth is, what is happening within a specific scenario is not related to that specific scenario. It’s the surrounding of it.
The environment that caused your sprint to fail is not the sprint itself, it’s the same rehashed “cultural” factor that was the culprit. So until the core issue is resolved, that by the way, everyone knows but can’t remove.. we should have a buffer.
e.g: You have 5 live bugs due to a serious tech debt issue. It took nearly half the sprint capacity out resulting in a chaos. Expecting that we won’t get another 5 bugs next sprint is simply fallacy.
Even though we know we may not get a whole week due to live bugs, we still manage to add a 2 weeks of work in the “Hope” that there will not be any bugs interrupting us. That planning you just did for the 2 weeks of work is there is already a “Stretched Target” based on false hope and false promises to stakeholders. Assume that the worst can happen again next week and rather than pushing more work, wait to see if we get free time when a developer can “Pull” the work instead.
C) By impressing the one, that matters the most
Impressing a Stakeholder is not the goal, certainly not when they have no data to prove that the theory they have about this new features becoming popular is correct. Impressing a Product Owner is not the goal for the same reason. Goal is to impress the one who is paying aka your end users. PO and therefore stakeholders are being the “messengers” for the development team and should always have data to prove the hypothesis before implementation.
If as a development team member you fail to ask for data, then don’t start crying about it later either. Refinement and Planning events are your chance to ask these questions and understand the context. If you don’t, you will allow these stretched targets to be placed in your sprint backlog and therefore will be responsible for your own unhappy work environment.
If you as a PO is pushing work as a stretched target to impress a stakeholder without knowing the actual capacity of the team, again, you are making a false promise. This is in your best interest to not commit extra work that you know are stretch targets. Certainly don’t promise based on assumptions like these. At the end of the sprint you will find an unhappy stakeholder and end users, even though your team was focusing on critical bug fixes to help them. You won’t get praised for those values as bugs fixes never get complimented rather criticised heavily with less informed phrases like “Bugs shouldn’t exist” or “Fix the bugs on your own time, I need my new feature”.
D) By being transparent about the true capacity
You know it’s summer time. You know half of the people have families. You know majority of them have kids who will not go to school due to their holidays. Also, you know some of them have booked a whole week off in advance, as early as 2 months.
If these above facts are being ignored in sprint planning, even a small story can become a stretch target. True capacity is when you ask the team about their “Gut Feeling”. I call it the “Gut Feeling Driven Development (GFDD)” where you think as a human, with your natural instincts and intuitions.
e.g: If I have booked my holiday from next Monday, I would probably fly out on a Friday night so I can use the weekend days to settle down and start enjoying the real holiday from Monday.
Yes, majority of us do it. If you don’t then you read the protip here first 🙂
So, if we are leaving on Friday night without leaving earlier than 6pm officially, we have to be well managed. I know few people who print their tickets off before leaving, calls the cab and web checkin so they have enough time when they arrive at the airport. Human do this, we all do this. That’s natural and no one will tell you to stop doing it. Therefore, our gut feeling will say that we will probably not be productive enough after lunch on the Friday to work on a complex refactor. Hence we should probably not commit that extra bit which have some unknowns.
It’s good to have a plan but it is more important to know that the plan can go out the window due to a stretched target. If this happens continuously we will feel demoralised and frustrated time to time.
Stop setting “Stretched Targets” in the hope that it might get done; it most probably won’t.
blogagility.com 