Our Stories Aren’t Getting Done: Hitting Roadblocks You Should Have Expected

Fitting The Pieces Together

Getting the work you commit to getting done in an iteration or sprint is not constrained to a conversation about Scrum or Scrumban. Timeboxing is common in almost all work to some extent. For example, the act of a person or a team saying what they will do to meet a need and when it will be done establishes a timebox and an expectation of performance. This expectation of performance is at the very heart of every technique, method, framework, and methodology. This expectation is often violated. Teams that chronically do not complete work they committed to in a sprint the third usual suspects is work hitting roadblocks before being shippable.

 

Our Stories Aren’t Getting Done: Taking More Work Into A Sprint

Over the years I have gravitated towards the idea that work entry issues are the single clearest indicator of problems in an organization. My first job after getting my Bachelors’s degree was for a women’s clothing company. We had salesmen jumping the queue to get their orders in the system or shipped earlier.  We created all sorts of rules to help control the process. The rules generated a lot of overhead and anger.  Reflecting on the last six months, I have seen many of the same issues with teams I have worked with. Work jumps the queue because no one takes the time to consider or reconsider urgency. How can software changes for daylight savings time ever be a surprise and become urgent? I am not naive enough to think every event or defect is predictable, but having pieces of work thrust into a sprint or iteration after it begins reflects failures of thought, control, and caring. The second category in our tour through why committed stories don’t get done in a sprint is not controlling the work entry process after a sprint starts. (If you think just having a work entry process is the solution, you are in for a rude awakening. Assuming you have a process, the process is never the root problem). Two of the most critical roots of work entry problems during a sprint/iteration are:

 

Too Much Scrum Meeting Time: Summary

Poking at any entrenched framework always elicits a response; almost all of the responses are well thought out and reasonable.  In the past five essays, we have explored two major questions: 

 

Too Much Meeting Time? Antipatterns Not To Try

Storms on the horizon!

In whatever flavor of agile that you are doing, meetings and ceremonies are lightning rods for resistance. In response, numerous approaches for improving the scenario have sprung up. Most of the tweaks or go-to techniques are a reflection of teams, coaches, guides, and Scrum Masters being agile and are great ideas for the situations a team might find itself in; a few, however, are bad ideas (perhaps for good reasons but bad nevertheless).

 

Whats In A Word – Overhead

Daybreak Over Lake Eire Is All About What Is Overhead

A brief interlude to our focus on meetings in agile frameworks to discuss the use of the word overhead.  

Once upon a time, my grandfather wanted me to be an accountant, just like he was. With all due respect to my uncle (who later became a lawyer), brother, and brother-in-law who found their way into that profession, that was just not in the cards for me. But despite that lack of desire, I have spent a lot of time with accounting over the years as a manager and business owner with income statements (not to mention all of the classes during my undergrad and grad studies) and balance sheets. The term overhead has a precise meaning. Overhead encompasses all the costs on the income statement except for direct labor, direct materials, and direct expenses. In all of the businesses I have been intimately involved with, day-to-day operations is a balancing act between spending on overhead and direct expenses. How much should be spent on planning, content marketing, office space, insurance, management, billing, and rent versus creating or selling a product or even billable time. Both overhead and direct expenses are important (we are assuming what you are doing is efficient and effective for the sake of discussion) but only to the point of diminishing returns. For example, recently I had a conversation with a person in the office down the hall (yes . . . I am working from home) about how much backlog refinement and prioritization was needed. The Scrum Guide suggests this can consume up to 10% of the capacity of the team. Note: I have asked Scrum Masters to validate my own experience and received a wide range of answers that rarely reach 10% (not a great sample) — the important part of the responses was that everyone has an opinion informed by how they practice and the context they find themselves in. My office neighbor suggested that the right amount, in their opinion, was that a team should spend the amount of time so that the backlog was refined to a point where periodic planning could occur and if someone got their story done with an hour left in the day that they could pull the next ticket. The focus was on doing just enough so that there could be a continuous flow of work.

 

Does Meeting Overhead Scale In Scrum?

Is a baby just a scaled down adult?

One of the most common complaints about using Scrum is the amount of meeting time.  In How Much Meeting Time, we used the meeting length recommendations from the Scrum Guide for a one month sprint to calculate the meeting burden rate. The number was 22.5%, assuming everyone is involved in each meeting and the meetings toe the line in terms of the guidance provided. One of the common recommendations to mute the meeting overhead problem is to use shorter sprints or iterations. 

 

How Much Meeting Time?

 

Meeting Time Is Not Always The High Point Of The Day

If you have ever performed as a Scrum Master or agile coach you have been asked about the overhead in Scrum. Overhead is almost always a codeword for meetings where “stuff” happens but nothing is built, coded, or tested, which in a software-centric scenario will drive a coder or tester up a wall. If we exclude (for the time being) some really bad practices that have been promoted and adopted, the amount of time in Scrum specific meetings is generally predictable.

 

SPaMCAST 573 – Backlog Prioritization Workflow, Real-life Application Architect, Essays and Discussions

http://www.spamcast.net

Play Now!
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

SPaMCAST 573 features our essay using a workflow to prioritize a backlog. Items on any backlog proliferate. Product backlogs used in agile and lean development approaches are no different.  Many outsiders have the mistaken notion that once on the list that that is the end of the story — let’s dissuade them of this idea.

 Gene Hughson brings his Form Follows Function column to the podcast.  Gene and I discussed his experience as an application architect. 

 Re-Read Saturday News

 

Prioritizing The Backlog: A Flow of Work

Lining things up!

Items on any backlog proliferate. Product backlogs used in agile and lean development approaches are no different.  Many outsiders have the mistaken notion that once on the list that is the end of the story. Mentally the story goes something like, I told that product owner in the email that I needed “x” and that it was important to a C-level executive, therefore it is in the backlog, the team will expedite their new priority, and magically new functionality will be delivered.

 

SPaMCAST 570 – Sprint Goals, Values, Essays and Discussions

http://www.spamcast.net

Play Now!
Subscribe: Apple Podcast
Check out the podcast on Google Play Music
Listen on Spotify!

I apologize for the delay in publication — ahhh the vagueries of travel!

SPaMCAST 570 features our essay on the components of good sprint goals. Sprint goals provide direction and energy, and they communicate with the outside world. A sprint goal should be a straightforward statement that a product owner should be able to craft quickly and then agree upon with a team. We provide a structure to keep goals simple and impactful.  

We will also have a visit from Susan Parente. In this installment of Susan’s Not a Scrumdamentalist column, we discuss value.  Value is core to many practices, the problem is that value is a very nebulous concept. Susan provides guidance. Continue the conversation with Susan at parente@s3-tec.com and visit her company at www.s3-tec.com