Frequently Asked Questions: Can I Resize A Story If It Is Harder Than We Thought?

I can’t resize the run even if is straight uphill both ways!

The question of resizing a story has many variations based on the rationale the asker is using. Rationales include stories:

• that the work is harder,
• take longer,
• for which someone else is going to do the work, or
• on which people missed the boat entirely.

If the answer given is no, the immediate next question is often “If not, then when does it make sense?”  Let’s start with the easy part of the answer.

 

Frequently Asked Questions: The Sprint Is Over, What Do I Do With Incomplete Stories?

When everything is done it is time to buckle and go home!

When I am asked what a team should do with stories that are incomplete at the end of a sprint or iteration I am reminded of the Jackson Browne song Load Out -Stay –

“Now the seats are all empty
Let the roadies take the stage
Pack it up and tear it down
They’re the first to come and last to leave”

Now the demonstration and retrospective are all done and despite the team’s best efforts, one or more stories do not meet the definition of done. The planning process that springs into action after the completion of one sprint often times feels sort of anticlimactic compared to the celebration that marks the end of an iteration. The team feels like the roadies as they swing back into action to pack up the last iteration and get the next ready to go. Shortcuts are sometimes taken with teams and product owners without thinking about “rolling-over” the escaped stories. Doing anything without thought is never a good idea. The three basic steps for dealing with incomplete stories are:

1. Return the incomplete stories (or other work items) to the backlog. Stories are either done or not done, there is no partial credit.
2. Re-prioritize the backlog based on all of the stories on the backlog. There are a number of approaches for prioritization ranging from most risky first to most valuable first. As part of the re-prioritization, reassess the approach to selecting work. At times it might be more important not to stop work on the story even when it does not meet the team’s prioritization strategy. Sometimes team members have just gotten to a point they can solve a problem and putting down might be less efficient, however, sometimes the need of the business and product owner will conflict (the product owner and business always win).
3. Plan (or re-plan) the work that will enter the team level planning process. Prioritize stories that are more important or return higher value ahead of the stories that you returned to the backlog unless there is a solid reason why that should happen.

The process for dealing with incomplete stories is straightforward. Incomplete stories have to compete for attention just like any other story. Being partially done does not generate a privileged position.

In addition to re-prioritization, items you should keep in mind when addressing incomplete stories.

1. Do not recognize any contribution to velocity or throughput for incomplete items. Remember no partial credit. Velocity is an average over a large number of sprints or iterations; it will balance out. Throughput is similar.
2. If you are tracking cycle time (and you should be) don’t reset the start date of the story. The start date for the piece of work begins when the team first starts to work on the item and ends when the story meets the definition of done.
3. If using story points and velocity as a planning tool don’t resize the story or your velocity will be incorrect and no amount of averaging will fix the problem.

Resist the urge just to roll over stories into the next sprint or iteration. Reassess whether they should be worked on in the next sprint (or even if they should be worked on at all) when compared to other work. Reassessing will make people uncomfortable; there was a commitment to complete an item when you drew it into the sprint. However, transparency and thought are core behaviors that every team should embrace.

 

Frequently Asked Questions: Can I Demo Work That Isn’t Done

Is A Demo A SAFe Area?

I have been asked many times whether it is “ok” to include work that is not complete in a demonstration/sprint review (I’ll use the term demo from now on).  The simple answer is that is a bad idea 95% percent of the time. Demos are agile’s mechanism to share what the team completed during the current sprint or iteration. The use of ‘complete’ is purposeful. It means the work meets the organization’s technical standards and is potentially deployable in production.  Complete mean stories that meet the definition of done – before the demo, not the next day. Teams define done before they begin work. Done typically includes steps such as coding, testing, documenting and reviewing. Unless the piece of work meets the definition of done (or a deviation agreed upon) then the work is not done. Demonstrating in progress material is a bad idea in most situations for many reasons.  Mixing done and not items in a demo:

 

Life Cycle of Consensus Decision Making

Making Christmas Cookies Requires A Concensus

Getting to a consensus decision is not always a walk in the park. Everyone seems to have a different path to the same goals, or if not a different path, at least an opinion on why other paths are better or worse. Everyone involved in reaching a consensus decision must start with the the belief that achieving consensus is the goal. If everyone is not operating in good faith there will be no consensus decision. Without an agreement to reach a mutually beneficial agreement one side winning or not agreeing become the only options. Based on the simple premise that people want to achieve a consensus decision, the question is how to get from many ideas down to few and finally to one a single idea or decision.

 

SPaMCAST 505 – Coaching, Tameflow and A Servant Management, Essays and Discussions

http://www.spamcast.net

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

SPaMCAST 505 features our recent essay titled, Coaching: Six Modes of Operation. On the surface, coaching is a fairly simple role. A coach has six basic modes of operation.  But…if you peel back the layers just a little bit you will find that coaching is part art and part science.

In the second spot of this week’s magazine have the penultimate session of our read of Steve Tendon and Wolfram Müller’s Hyper-Productive Knowledge Work Performance, The TameFlow Approach.  

I have moved things around a bit and complete this edition of the SPaMCAST with an essay on servant leadership from the Software Sensei, Kim Pries.  Regardless of how you define servant leadership, I think we would all agree that good leadership is critical.

Re-Read Saturday News

This week we begin the read of The Checklist Manifesto by Atul Gawande (use the link and buy a copy so you can read along). The version of the book we are reading is published by Metropolitan Books, 2009 and is the 22nd printing. The book has nine chapters and with acknowledgments has 209 pages. My reading plan is one chapter per week, therefore, the re-read will span 11 weeks.  

 

Current Installment:

Week 1 – Approach and Introduction – https://bit.ly/2LYi9Lv

 

Next SPaMCAST

SPaMCAST 506 will feature our interview with Mark Kilby.  Mark and I discussed agile in distributed environments. Agile in distributed environments is doable but it isn’t easy, Mark provides guidance and advice.

 

Coaching: Which Course of Action?

Time to Intervene?

Coaches are more than someone lurking over your shoulder watching your every move.  The goal of coaching is to MAKE A DIFFERENCE in someone’s or some group’s life. To make a difference, coaches need to intervene.  The goal of any intervention is to change behavior to fulfill the coachee’s development plan (this is why agreeing up front to what you want to accomplish is a big deal). Changing behavior requires some combination of:

1. Trying new behaviors and getting feedback,
2. Building and trying new skills,
3. Participating in training,
4. Enhancing relationships with the right people
5. Seeking out mentors to grow the whole person, and
6. Accepting input from stakeholders on goals and behaviors.

 

SPaMCAST 503 – The Knife’s Edge of Change, Muda and People, Communication

http://www.spamcast.net

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

SPaMCAST 503 features our essay “Culture: The Knife’s Edge of Change.”  I have often heard the line, culture eats change for breakfast. Culture, culture, culture – the success of every change that is considered or implemented balances on the knife edge of culture. Aligning cultures so that change is possible requires seeing the differences and then minimizing enough of those differences to allow change to happen.

We also have an installment of the Alpha and Omega of Product Development with Jon M Quigley.  In this installment of Jon’s wonderful column, we discuss the muda of underutilizing people. Muda, waste, is not just generated through process or transforming raw material.  

We conclude with a visit with Gene Hughson.  We discuss an entry from his Form Follows Function Blog titled: “When asked for the time, don’t explain how your watch works”. Communications between the user and technical domains is fraught with difficulties. A problem? As Gene always says,  “exactly!”

Re-Read Saturday News

We will complete our re-read of Turn The Ship Around next week with a few final thoughts.  The next book in the series will be The Checklist Manifesto  (use the link and buy a copy so you can read along) by Atul Gawande. Today we complete re-reading the chapters in  L. David Marquet’s Turn the Ship Around!  Chapter 28, 29 and Afterthoughts complete Marquet’s reflection on the leader-leader model and his journey of discovery.

Current Installment:

Week 18: A New Method of Resupplying and Ripples  – https://bit.ly/2mgVFtI