How to Plan Software : Six Ways to Improve Your Scrum Planning Meeting

So many Scrum teams struggle with planning on every level. Whether it be creating initial stories, decomposing stories, estimating stories or breaking them down into tasks. There is a notion that planning should be easy because we are smart, but the reality is planning is just plain hard. Teams tend to focus on estimation and how it is bad, meaningless or just a waste. It leaves them begging for someone to help them learn how to plan software.

Sprint Planning

Copyright Antgirl

“A goal without a plan is just a wish.” – Antoine de Saint-Exupery

Why do teams find things always take longer than expected? How can they spend an hour or even a full day planning one or two weeks worth of work to only find that they missed so much of the work necessary to actually complete the work? They scratch their heads because they just can’t seem to get better at planning.

Here are a few tips change how you plan software to become more effective and efficient.

  1. Draw. That is right, get up to a white board and draw out your thoughts. Not everyone thinks, understands or processes information the same way. Your brain works differently when it comprehends visually and when you express yourself through writing/drawing. Open up new neural pathways to think about the problems at hand.
    • Visualize the flow of how data, interaction or experience works.
    • Wireframe out anything visual so that there are concrete samples of how it works.
  2. Ask and answer the following questions. They will help guide discussion around easy to forget or often assumed interactions.
    • How do I get there?
    • What do I do when I am there?
    • What happens when I do it?
    • What happens if it goes right?
    • What happens if it goes wrong?
    • Where do I go when I am done?
  3. Verify that all the acceptance criteria/conditions of satisfaction have been covered.
  4. Task the work based on the information created in the above steps
  5. If you are estimating time on tasks make no single task greater than 2 hours.
  6. Commit as a team to the results desired from executing the plan

(ProTip: Use the above as a checklist before committing to each story)

Many people feel that planning is a waste. This may be true if there is no desire to understand the outcome or the path to get there. The more value placed on having some prediction of how things will play out, the more desirable planning becomes. It is important to note that all planning is a form of prediction. Predictions are not 100% reliable, but that does not render them useless by default.

The power of the plan lies the ability to commit to executing the intended results.  Not necessarily the path taken to do so.

“Unless commitment is made, there are only promises and hopes; but no plans.” – Peter Drucker

In the end. Do what you feel is right.

Calculating Lead Times While Waiting at the Motor Vehicle Department

I am fascinated with how systems work and how things are designed.  I put myself in observation mode as much as possible.  Today I had to head the Motor Vehicle Department (MVD) to get a few automobile titles transferred into my name.

I opened the door to a facility packed full of people.  The procedure here is that you stand in line to get a ticket.  That ticket is issued to you with a prefix.  The prefix is the group that you are assigned to.  I was assigned group J, which happens to be for issues involving title changes.  As I was standing in line I started to pay attention to how groups were called and in my head I noticed that it felt like each window was taking about 5 minutes to process.

When I received my ticket J616.  I realized that there were 18 tickets ahead of me.  It was 11:15 am.  I quickly did the math 18 tickets * 5 mins = 90 minutes or 1 hour and 30 minutes.  I should be done around 12:45 pm.  I had a lunch date at noon.  I didn’t call to cancel it immediately.  I figured I would calculate the cycle time for a few tickets and then figure out the lead time before rearranging my lunch plans.

I pulled out my phone and immediately started a timer.  The minute the first J ticket was called I hit “lap”.  First cycle time 5 minutes 11 seconds.  If I multiplied that by the remaining work 17 items and saw a lead time of 1 hour 28 minutes.  I texted my friends and asked if they could give me another 10 minutes to determine if our lunch plans were in jeopardy.   Two tickets later and the average cycle time had dropped to 2 minutes 43 seconds and the lead time was 40 minutes.  At that point I knew it would be cutting it razor close and so I opted to let them know it wasn’t prudent for me to hold them up and that I would be checking out of lunch.

MVD Cycle Time

Included above is the full source of data for my time at the MVD.   Cycle Time is the amount of time between completed tickets.  Running Time is the time of day at the cycle count interval.  Running Average is the average cycle time for all tickets completed through that cycle.  Lead time is the Average Cycle Time * Work In Progress (Tickets Remaining).  Est Finish Time is Running Time (Current Clock Time) + Lead Time.  Var From Reality is how much variance there was between that estimated time and the actual time completed.  You can see how calculating lead time using a cycle count can be used to predict completion time.

Some things I found fascinating.  The average variance against actual was 59 seconds.  The variance was never greater than 23 minutes.  My original estimates of 5 minute cycles wasn’t too far off from the 4 minute 12 second actual and the estimate of 1 hour 30 minutes was over stated as the actual was only 1 hour 11 minutes.

I know people tend to hate estimating, but I think it is because they are poor observers and can’t see the system as a whole in play.  Additionally, it only took me about 5 minutes to come up with the estimate and about 5 minutes to capture data and reconfigure my estimate based on reality.  What are some of your experiences playing with data to make predictions?

How to Run a Lean Coffee Meeting

During a session at Agile Open Northwest convened by Arlo Belshee a number of us discussed good ideas (Lean Coffee, Core Protocols, Open Space Technology, Technical Practices and Team Practices) that needed to be spread.  These are things we take for granted in the Agile community, but when introducing them to people it becomes obvious that they are not as common as we think they are.

Agile Weekly put together this video showing you how to run a Lean Coffee meeting.

When you need a structured, but agenda-less meeting. Lean Coffee is a great way to allow participants to gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated.


Scrum Burndown Chart Hack

Hours Burndown Chart

Hours Burndown

Recently a team asked about a visual indicator to show the projection of their work for their hours and points burndown charts during the sprint.  When indicating that a piece of string would work, it dawned on me that we have pipe cleaners in our Facilitator Toolkits.  Turns out they are the perfect size for an 8-1/2″ x 11″ piece of paper and easily wrap around push pins used on the board for a burndown chart.  Plus they come in some really fantastic colors.

Points Burndown Chart

Points Burndown

Agile Open Southwest Recap

Open Spaces always tend to amaze me.  They really are the right people in the right place at the right time.  When we kicked off Agile Open Southwest, I was a little bit nervous about what might come out.  As always, I was left absolutely amazed.  It was great seeing old friends and meeting new ones.  Finding everyone was a different place on their journey yet still able to be find common ground and learn from one another.

Alan Dayley led a great session on Permission Restriction.  What is holding us back?

Jade Meskill helped us articulate what the Phoenix Agile community could look like using Legos.

Roy van de Water helped us discover how we can learn together and what might be holding back internal improvement communities.

I was able to have a frank discussion about excellence and how it can propel us to the next level.

We broke bread together and got to know each other.

Most importantly we were human with other and left encouraged we are not alone in our quest for improvement.

I can’t wait for next year.

Don’t Make Your Retrospectives Confusing

If explaining an activity in a retrospective takes more than a minute or two it probably isn’t very effective. Don’t fall into the trap of making things too complex.  Activities shouldn’t be complicated they should be fluid. Giving participants too many options and being unclear with instructions makes it difficult to fluid with sharing thoughts.

This tends to frustrate the participants and make them disengage. Good facilitation makes sure everyone has high energy and is actively participating. Be sure that you come prepared and articulate with clarity and brevity what you want during activities. If something isn’t working don’t be afraid to adjust it on the fly. Make it more simple and keep the flow going.

Remember to retrospect on your performance regularly, it is the quickest way to improve your facilitation skills.

Retrospectives. When Facilitating. Facilitate. Don’t Participate.

As a ScrumMaster when you are “running” a retrospective it is easy to fall into the trap of actively participating in it. It is extremely difficult to do this well (if not impossible), because your role should be as a facilitator not a participant. The minute you start participating you are no longer neutral and severely impact your ability to effectively facilitate.

Sometimes the need to take advantage of coaching moment or provide input is too great. One way to handle this is let the group know you are taking your facilitator hat off for a moment and acting as a coach or a participant to briefly add the input and then put your facilitator hat back on. This should be used sparingly and know that it will greatly affect your ability to be seen as neutral. However, it will at least signal to the participants your understanding that a facilitator should not be a participant. Clear boundaries are good.

A way to prevent frustration (and burn out) is to not be the one always facilitating the retrospective. Ask another scrum master to switch it up with you. Ask a team member if they want a turn. They might just surprise you.

Estimates are Evil!

A young man was bitten by a pitbull when he was 10.  Ever since then every time he has noticed a pitbull it is barking, snarling and threatening to him.  He is now 35.  He believes that pitbull’s are a vicious breed and that they should not be family pets.

Many developers feel the same way about estimates.  At one time they worked for a company that abused them with estimates.  Ever since then they see all the attributes of estimation as evil and avoid them at all cost.  Now they believe that estimates are a vicious breed and should not be used in development ever.

Estimates like pitbulls can be deadly, but not all estimates or pitbulls are evil.  Be careful when using absolutes.

Should Senior Developers Pair Program?

I am a proponent of pairing (not just for programming). Anytime I introduce it to a new team I get a number of objections. The most prominent is that pairing slows me down (because I am so awesome and everyone else sucks so bad).

The logic goes something like, if I am good (and fast) and you are good (and fast) we could be just as fast alone as we are together. Since we are both good do we really need to pair? or I am good (and fast) but you are bad (and slow) so pairing with you means we will never get anything done because you are slowing me down too much. Maybe I am good (and fast) but you are okay (and not fast or slow) then maybe we should pair because we can be fast but I can make you better.

The problem here is that there is a belief that pairing is about going faster. It isn’t (at least not in the short term). It is about achieving something greater together than we could alone. A great African proverb goes something like “If you want to go fast, go alone, if you want to go far, go together“. Pairing is about improving together.

So I might slow you down. It means I am learning and by default you are teaching. Together we are both improving. If we think of it as a marathon instead of sprint we can see that together we can get much farther by slowing down to speed up.

Definitions of Pairing Partners: (Dreyfuss Model)

Novice (Advanced Beginner)
Has little domain and/or technical understanding. This is your classic n00b, junior developer or intern.

Competent (Proficient)
Has some domain and/or technical understanding. This is your standard developer.

Has deep understanding of the domain and/or technical aspects of the system. This is your senior developer.

Here is my theory on combinations of pairing:

Novice and Novice
In this match up the production will be very slow, but the learning will be tremendously high. This is because the pair is totally reliant on each other for discovery because they have no other choice and no existing knowledge.
Learning: High Production: Low

Novice and Competent
Production will be moderate as the competent programmer will often not try to explain too much and will work at close to a normal pace for themselves bringing the novice up to their speed. The learning will be fairly high because neither has all the answers and are dependent on each other.
Learning: High Production: Medium

Novice and Expert
Production will be low as the expert is often a poor teacher and goes into too much detail explain concepts too difficult for the novice. The novice likely will ask a lot of questions and be confused. However production will still be greater than two novices. The novice will likely learn a lot, but will be drinking from a fire hose while the expert will learn new things by teaching. Overall yielding a medium learning level.
Learning: Medium Production: Medium

Competent and Competent
Production will go at a good pace as the both participants are at the same level allowing for a cadence to develop. Learning will be good for both as their shared level will allow for maximum trust.
Learning: Medium Production: Medium

Competent and Expert
Production will be high in most cases as the expert will not have to explain things in detail. Learning will be medium as the competent participant is often reluctant ask questions and the expert tends to lean towards auto pilot mode.
Learning: High Production: Medium

Expert and Expert
Production will be high as the energy level will be strong and the cadence rhythmic. Learning will be low as neither participant will likely ask a lot of questions or seek new understanding.
Learning: Low Production: High

So why bother pairing if production is “High” in a majority of pairings? Because we are not worried about this iteration/sprint we are worried about 100 iteration/sprints from now. Below you can see the difference in production over time between teams that do promiscuous pairing of multiple types versus teams that do no pairing at all.

Together (Pairing)


Alone (Not Pairing)









Does your team want to go fast or do they want to go far?

5 Ways to Tell if Your DevOps Relationship is Failing You

Here are five smells seen in organizations that are not fully cross functional and are trying to simulate cross functionality with some variation of “DevOps“.

  1. The development team doesn’t have a fully local development stack on their machines/pairing stations.
  2. Someone other than the development team deploys the software. (The exception being an automated continuous deployment created/owned by the development team)
  3. Someone other than the development team owns the build/continuous integration process (or you don’t have one at all)
  4. The development team can’t create/deploy a simulated production environment for any version of the software with data in under 60 minutes.
  5. The deployment process is not fully automated with the ability to automatically rollback.

The above definition of “development team” is the team writing the application.