As the story goes… A city once kept a knotted piece of rope so intricately entangled that it was impossible to untie. For all who tried. Alexander the Great walks into town, and when he tries, he can’t even find the ends of the rope…so he uses his sword to cut the knot in half. A solution from the battlefield brought into rope work. The Gordian knot is now a problem that has been solved, although in a very nontraditional, unexpected manner. We used to get hung up on hours- how long something took to complete. We were usually wrong. The human species needed clocks because temporal management may not be entirely instinctive to us. We changed the focus to get up out of hours and instead focus on task completion. Doing the right thing and in alignment with the business. Having an urgency for a time box that is the same cadence, always helps with our urgency, commitment and focus.
Analogy. It is a way of thinking which transfers meaning or insight from one topic into a different realm, subject or topic. From analogy we problem-solve, make decisions, explain, communicate, compare, create similes and say this thing is like some other thing. It is often very useful when the work we do constantly changes – and yet we still need to compare when this work is BIGGER or smaller than some other type of work we did. Humans long ago knew to size up danger from a big bear immediately and differently than from seeing a little rabbit. Same with problem solving. Stay with me… this all ties together eventually.
Scrum uses story points to estimate work. That’s right. Something that sounds made up and imaginary to be told to young children at bedtime. This method also works really well for estimating work. Also, just like anything else – at times can be misused and misunderstood. Teams may have a series of cards, or use cell phones to display a number that is somewhere close to the Fibonacci series. 0,1,2,3,5,8,13,21,34,55 or maybe 0,1,3,5,8,13,20,40,100. We talk about the work or ‘story’ that needs to be completed, and then we vote a sizing. If we disagree then we talk about why we voted as we did, what we may have missed. We typically capture this conversation for future reference. It is one level at which we will assess the work before we actually commit to doing it, as a team, later.
I wanted to point out some common bumps in the road that teams can have. Irregardless if they are just starting along their agile journey, or if they have been estimating stories for years.
Troubles with Story Points – what to avoid:
– Anchoring. Don’t let one person consistently shout out their determination before we all vote at the same time. – This typically anchors the rest of the group, absolves them from any critical thinking or questions and does not help teach what may be involved to others… Don’t anchor the estimate – just speak to what is involved, and effort.
–Consensus. Do we all need to agree and stay till the wee hours of the night or is a simple majority OK? Does our majority make someone consistently irrelevant? Does this team member still not seem to get it? I want to emphasize the team working together quickly and well. Moving forward. If you want to see and compare some other teams that either charge in and problem solve or seem to stop and thrash when presented with a problem or challenge – I usually like showing teams these videos. These are teams going through an LRC – Leadership Reaction Course. I often stop along the way to ask what they see is happening. LRC1 (How do the 3 teams compare?, Is one team placing emphasis on blame or where they succeeded?) and LRC2 (Did they change their process along the way? What did the team forget?)
– Bidding.. This is not lowest bidder. – If Madam X does it then it’s a 21, if Mr. Z does it, then it’s a 55. Discontinue the delamination of your team. Discourage the work of the roles ever separating, not mixing, learning, improving until we are no longer a team. A team leverage resources, trusts and exhibits a swarming behavior that everyone will pitch in to help get the work done.
– Re-estimate the past. Don’t. Just keep moving forward. Emphasize to the team that I want you better on the estimates were are making from this point forward. There are also exceptions to almost every rule. The only re-estimation I might do, is if this is a special reference story that your team can use to compare the size of OTHER work that it will estimate in the future. Perhaps this work is significant and sticks out in tribal memory of the team. This story was really a 20 – and since it is sooo vivid in the team’s consciousness, it is now a standard for the next quarter to compare the SIZE and effort of different types of work to this particularly memorable one.
– Making in-between values to be more precise… Don’t. Once we start using 3.5 and 26, then we are right back to arguing hours. The results are just as successful. Be comforted in the thought that statistical distribution of all a team’s size ‘8’ stories – some were bigger, some were smaller but most will be pretty close. In fact i might have had an 8 that turned out to overlap a smaller 13. – Again don’t re-estimate. Just become better and keep moving forward. Trust that there is a variability to these mutable, intangible, team specific story points.
–The team is constantly changing. A team that is allowed to stabilize, go through storming, norming and performing, will have an easier time and more consistent estimates.
–The team is judged by velocity only. Don’t. Take a look at the work they are doing even without the estimates. Is it challenging, is the team growing to take on different types of work? How predictable are they for their commitments. How robust and reliable is the solution they create?
– The team just has 1 big story. Really? all the time? This might point to a team’s lack of ability to critically break work down, narrow scope, or improve processes. 1,2,3,5, are fairly close, as they should be. At a smaller scale we should be more accurate. The Scrum master acts as a historian for the team and should be able to answer – What was the most amount of stories we estimated in an hour? What was the biggest story we ever completed? What was the most (number irregardless of size) stories we ever completed? What is our average number of story points? These aren’t to prevent a team so much as to ask the question, and have the team ponder, think differently for a moment and either confirm or change their answer on whether they feel this work can be completed.
– Recycling. Normally a good thing right? This has to do more with the story that with the sizing. We do iterate to improve things. Except when it is the SAME old story again and again. Even kids pick up on this one. – I have known some teams to hide in a particular story and do the SAME work over and over and over. They never finished a good deliverable. Not a good way to represent value.
–No Guess. No Conversation. Sometimes this is a matter that the stories are a bit too fuzzy. Perhaps some time has to be set aside to make these a bit more ‘mature’, better vetted, or formed if this is not happening naturally in the moment. Don’t allow team members to consistently abstain either. There is nothing to be wrong about – this is a lean in moment to help problem solve and see from everyone what might be involved in doing this work.
–Cards – Have some made for your team! There are websites to do this or just get to a printer that has a good card stock. I would put things on the back of the cards that meant something to the teams. This could be personas – typical of those different people that use the software. It could also be reference stories of typical work the team has estimated and done before for that number size. These tended to be more useful and easier to guide the tempo of the voting than everyone using cell phones.
Flexibility is far more valued than rigidity.
For the project managers: Money burn down – yep we can still do it, even with story points. This is done indirectly by empirical analysis once the system (team, time box) has a chance to stabilize. A project manager might take an average salary and at a sustainable pace (40 hrs a week), this means that our average velocity actually has a $ amount. Though I don’t like doing this – it can bring in a sense of perspective for cost and priority. Is the team’s attention on this for a week worth the cost? There are a LOT of intangibles though – like better quality and trust of the end-user. Sometimes there is an acceptable higher cost – because a team with the talent to do this more quickly is busy working on something with a higher priority and we are balancing the capacity of the program to complete the must haves in a release.
ANALOGY AND COMPARISON – This is helping us at one-level, think critically about what can be completed in a sprint… and the team teaches ourselves to become better problem solvers and know our capacity.
What we are learning how to be honest with ourselves, to tighten up sprint boundaries for what we can accomplish and show to the business as being complete and done. We are earning some trust when done successfully.
It is the delivery of working software that truly matters. The story point estimation is simply one level of thinking in order to view and assess the risk and size of the team’s commitment or forecast for several chunks of work.
At first my concern for a new team is the commitment for this sprint.. but over time… we emphasize and cherish even more, the ability of the team to problem solve and right fit the stories into the sprint. Then we get bigger about the work that fits into a release, and across a couple teams.
As ever, here’s to everyone being able to cut through a Gordian knot of their own.