When Do Story Points Make Sense?

Story Points: No Parking

Story points are a planning tool that has proponents and opponents. Like most tools, story points are not prima facie evil, it is only through misuse that they are problematic.  Problems tend to occur because leader, managers, and team members have a need (or at least a very strong desire) to know when a piece work will be done, what they are going to do next, whether they are meeting expectations, and in many cases what something will cost. Story points are a relative measure, a proxy of a proxy that makes answering any of these questions with precision very difficult. The best anyone can hope for is that the answers story points provide are accurate enough and provide a coherent feedback loop for teams. This could be considered damning with faint praise, however, in the right circumstances story points are a useful tool for a TEAM. I am a proponent of using story points in three scenarios.

 

Story Points – Leave Them, Don’t Love Them

Story Points Are A Reflection!

Last week Anthony Mersino published a blog entry titled Story Points – Love Them or Leave Them? He ended his blog entry with the question, “What do you think?” I know it will shock some of you, but I have an opinion. An opinion born from observation, research, and hands-on experience. Story points are specific to every team that uses them. I have used and still do use story points in some very specific scenarios. To answer Anthony’s question, over the years I have migrated into the “leave them” camp with a few caveats (we will tackle those later in the week). Story Points have a litany of problems including a myriad of definitions, they are a poor tool to compare performance, they are conflated with hours, and they institutionalize bias (see The Slow End Of Story Points for in-depth discussions on these points). In the last round of articles I wrote on story points, I did not address the basic conceit at the core of story points. Story points assume that teams need to size pieces of work in order to know whether the work is too big or too risky to accomplish in a specific period of time. That assumption is wrong for any team that has worked together for more than a sprint/iteration or two and breaks its work down, plans and commits to that work, and then use the results from that sprint or iteration to improve how they work. These steps are basic activities for an Agile team. The inspect and adapt feedback loop provides an experiential platform that negates the need to have a debate over Cohn’s Numbers or an entry on the Fibonacci scale. That time is better spent discussing what the work is that is being requested by the product owner and how that work is going to be delivered.

 

SPaMCAST 549 – Seven Issues Testers Experience Being Agile, Distributed Agile, Essays and Discussions

http://www.spamcast.net

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

SPaMCAST 549 features our essay Seven Issues Testers Experience Being Agile.  Recently I attended the QAI Quest Conference in Chicago, during the conference I got to talk with lots of people from across the development spectrum. From the conversations and workshops, I identified seven common threads that test and quality focused personal experience being or trying to be agile. In order to be agile, not just do agile, we need to tackle these seven issues

We also have the completion of Susan Parente’s three-installment discussion of distributed agile.  In this installment of Not a Scrumdamentalist, Susan discusses tools and whether they are the hurdle some people make them out to be.  

 

SPaMCAST 542 – Kittens, Exploding Kittens, and Risk-Based Planning: An Interview With Kevin Rush

http://www.spamcast.net

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

SPaMCAST 542 features our interview with Kevin Rush. Mr. Rush has developed an innovative approach to facilitate sprint/iteration planning.  Kittens, exploding kittens, and fat cats are used to help teams probe whether the team understands the story and if the story is broken down well enough for the team to reduce the risk of failure.  All change agents talk about making changes at the team level but many fail to change how they work, Kevin suggests that experimenting with different approaches is eating our dog food. Way too many pet metaphors, but a great discussion.

Kevin’s Bio

Kevin is a certified Scrum Master and Agility Enablement leader at Hyland Software. Before coming to Hyland he worked as an innovation consultant and coach with for-profit and nonprofit organizations throughout Northeast Ohio. A graduate from DeVry University he spent time as Technology Coordinator for several local school districts before transitioning to ministry then back to tech! When he’s not working with teams and organizations he spends his time with his beautiful wife, Sondra, and their three beautiful daughters.

 

SPaMCAST 536 – An Executives View of Agile Transformations, An Interview with David Sohmer

http://www.spamcast.net

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

SPaMCAST 536 features our interview with Dave Sohmer. Dave is an executive that has led two separate major agile transformations.  Mr. Sohmer provides an executive’s perspective on the impact of adopting agile in two major financial institutions. The two very different companies took to two very different approaches to agile.

Bio:

Dave Sohmer is a technology and operations executive with over 25 years of experience.  He has spent many years in the code but has come to enjoy the people and process side of software almost as much.  Dave has built and led many development teams at scale at Northern Trust and Bank of America Merrill Lynch over the last 20 years. Over that time he has come to believe in the power of the team as the fundamental unit that unlocks business agility.  He has championed two large scale Lean Scrum transformations within the financial services sector and has come to appreciate that a healthy mix of Lean principles, Agile values, Scrum by the book, XP practices and common sense will radically change your business’s view of technology from misunderstood adversary to trusted partner.

LinkedIn: linkedin.com/in/davidasohmer

Email: david@sohmer.net

Re-Read Saturday News
We continue our re-read of The Tipping Point by Malcolm Gladwell. Chapter Six of Malcolm Gladwell’s The Tipping Point continues the discussion of the role of context in approaching a tipping point.  Stop borrowing your best friends copy and buy a copy of the book for yourself!  

Check out the current entry of Re-Read Saturday at www.tcagley.wordpress.com

Next SPaMCAST
SPaMCAST 537 will feature an essay on the use of assessments for agile efforts.  Assessments come under a wide variety of names: appraisals, health checks, audit or even assessments. These terms are commonly conflated.  Assessments are a tool to prove a point. The essay in the cast explores the myriad types and reasons for assessments.

We will also have a new column from the Software Sensei, Kim Pries.

 

Scrumban: Different Genie, Different Bottle

Sometimes you just have to . . .

I was originally asked to help provide additional ideas to convince a Scrum Master that had recently joined a team due to a company rotation policy not to give up Scrum (full scenario). The change in team composition led to problems.  On the surface, the decision by the wayward Scrum Master to abandon Scrum in favor of Kanban is an emotional reaction and does not reflect many of the leadership problems the Scrum Master introduced. Assuming that the leadership problems have been sorted, it is time to contemplate how the team will work as they move forward.  The question was posed as use Scrum or use Kanban; however, there is a third (and possibly better) answer. Do both — Scrumban.

 

Kanban: Throwing Away The Bottle

Sometimes you just have to . . .

If you were not moved by the case for Scrum then the next step, just as suggested by our wayward Scrum Master is kanban. If re-committing to Scrum is equivalent to putting the genie back in the bottle, then adopting kanban is the equivalent to throwing the bottle away. Kanban is a flow-based framework based that originated from concepts in lean manufacturing that have been tuned for software related projects.  A team or organization using kanban pulls work from a workflow (across the board) at a pace equal to the work in process limits for each step in the process. Kanban requires team members to have the discipline to observe the policies set for the team such as only pulling new work when it can be started and swarming to bottlenecks when they are identified. Efficient and effective teams using kanban are very disciplined; whether this is because of the people or the framework is debatable.