Imagine you and I were looking up at two skyscrapers, and I asked you how high you thought one of them was. You'd probably find it pretty hard to tell whether it was 50m or 500m. But what if I asked you how high the second one was in relation to the first? I bet you'd be able to say it was about a third larger, for example. If you could measure the height of the first building, it'd be much easier then to estimate the height of the second.
People are generally better at estimating relative size than absolute - and this doesn't just apply to buildings. In software development, estimating relative size - usually with story points - and then measuring how many points we can deliver in a given time is generally more accurate than trying to figure out how long a task will take in days, and then allowing for the general daily faffing.
Most developers have spent their careers estimating in time though, and making the transition to story points isn't always easy. There are a few things I've seen recently that can help people get comfortable more quickly with story points.
1. Estimate in a group with developers who have experience with story points.
Having developers in the group who have done it before is probably the best way to get the developers new to story points up and running quickly. They can set a good example and reassure the others that the technique does work. In an inexperienced group, doubt can plague the group and undermine the estimates.
2. You don't have to estimate QA and Dev effort together.
Some agile teams try to estimate the effort to complete a story to include all of the dev and QA work, but this is really, really hard. QA and development are very different skillsets, and it can be frustrating for the team members to have to estimate something they can't be expected to understand.
For teams practicing test driven development and writing unit tests, QA involvement can happen at the start and end of story development, with the QA and BA working together to write acceptance tests prior to development and sign off the story when development is complete. Unless the QA effort is really significant, it's probably OK to represent the dev effort in story points, and have the QAs check the estimates, and just highlight any that are unusually low but might cause a bottle neck for them.
3. Agree a good scale.
There are two common scales for story points: the fibonacci sequence and the power of two, and both work well. The important thing is to agree a sequence in advance, and ensure the upper bound isn't too high. Either 1, 2, 3, 5, 8 or 1, 2, 4, 8 works well. You might choose to use 0 and 0.5 for really small things like configuration. 13 or 16 point estimates become less meaningful and far less accurate - can you really think in terms of 13 times the size of a 1 point story?
Give developers a question mark for the stories they can't estimate - these are the ones that are too big, or have too many open questions. They'll need more analysis or splitting before you can estimate.
4. Get good story granularity.
Whatever estimation scale your developers agree, your stories will need to be small enough to fit into it. Usually your largest stories should be no more than eight times as big as the smallest ones, and you'll need to be clear about what each of them really means.
The best way to judge the granularity is to have some of the more experienced developers review them before you start estimating. This doesn't have to take very long. On a recent project, we spent maybe three or four sessions with developers prior to estimation, each one about an hour long. It might sound a lot, but it's worth it - there were only two stories out of nearly 700 that they couldn't estimate.
5. Capture Low, Likely and High estimates.
In some versions of planning poker, you're supposed to aim for convergence between the team members on an estimate. You can do two or three rounds of estimates on a single story to try and get there. The trouble is that this can take a long time, and get frustrating if team members don't want to budge.
One way of getting around this is to capture low, medium and high estimates, taking the lowest, highest and middle ground from the estimates from all of the developers. They may not agree, that's OK, and it's also OK to capture the disagreement and move on.
The low and high values can be used to weight estimates for release planning.
6. Get comfortable with assumptions.
Stories are a promise for a conversation. You won't know all the details of the requirement when you estimate, it's agile, you're not supposed to. In some cases, you might have a better idea in your head than what's written down on the card.
It's OK to make an estimate based on assumptions (make sure you record the assumptions with the story though!) Assumptions can help move the estimation along faster. If it turns out the assumption was wrong, then the estimate is also wrong and can be redone later.
7. Be prepared for estimation to take a long time - especially at the start!
In a recent estimation session I attended, the first estimate took well over ten minutes of discussion to arrive at. Some people were looking at the list of stories and starting to sweat and wonder if we'd ever make it through to the end!
This is normal, especially in a newly formed team, they will take time to speed up, but they will get there. Don't try and finish estimation in an hour, it's not going to happen unless you've got a week long project. The team need an adequate amount of time to not feel stressed and get used to estimates, it will pay off when you're able to speed through fifty stories in an hour and get an accurate release plan later on.
8. Calibrate several stories in advance with a smaller group.
Calibration is the process by which you arrive at the initial size of a story point. It's time consuming and challenging - we took an hour or so to calibrate four stories. If you're working with a mixed team of developers who are both experienced with and new to story points, it's worth taking the time with those who are more comfortable with story points to do the calibration first.
It's key to pick the right stories for calibration. Whatever scale you choose, find a story that fits each bracket - you may have to go through several to get there. When you're done, pin them up on the wall and refer back to them for the first few rounds of estimation: "Is this the same as that 3 point story on the wall?"
9. Use ideal days in the initial calibration.
To start calibration, use a scale like 1 ideal day = 1 story point - but only use it for the initial calibration! Once you have your scale, don't refer back to ideal days as it will muddy the waters - it's OK to use to get going, but after that try to just size against the other stories and forget about duration.
10. Triangulate with a sample of stories.
Triangulation, or cross checking the consistency your estimates, can happen at any point during or even after estimation.
You don't have to check every single story if you have a lot. One technique is to sample 5-10 from the middle estimates (e.g. 1, 3 and 5) and compare them. If they're reasonably consistent within and across the estimates (i.e. a 3 is about three times a 1) there's no need to compare any more.
A quick conclusion ...
Like many aspects of agile, estimating with story points is not easy, but it is effective. I plan to write soon about going on to use the estimates for release planning, so stay tuned!
I've heard a few people mention the dreaded "O" word on the project I'm working on (that's "overtime" in case you didn't guess) I believe very strongly in encouraging a sustainable pace instead of working overtime to get things done, and I think it's even more important on agile projects.
Here's a few reasons why, based on my experience:
- Agile projects are planned based on a team's velocity. If the team had to work overtime to achieve a certain velocity, they'll have to work overtime again to achieve the same velocity. This means planning is based on a greater capacity than is in the team, which is not good!
- The more time people spend working, the more tired they get. Tired people work slower, and make more mistakes, which ultimately means work takes longer. So the overtime doesn't really speed things up.
- People need to take time out of work to spend with their families, or on their own lives. A healthy work life balance can result in better motivation, which ultimately helps team motivation, and the work goes faster.
- In agile projects in particular, the iterations form a steady cycle. Unlike waterfall, where there can be a frantic, stressful time followed by a lull, in iterative development there isn't time to slow down. It's important to keep to a pace that the team can maintain without feeling burned out.
While I do think there's the odd occasion that working overtime can be the right thing to do - for example, pulling an all-nighter to get that important release out of the door - it's just not the answer for projects that are falling behind. It's going to end in lower quality, lower motivation ... or both.
I learned an important lesson this week about how powerful it is when people are outwardly positive about the project and work they are doing.
Having worked on projects in the past where the team were frustrated and had a tendency to demonstrate that quite vocally - something which I am definitely guilty of doing - at first, I really noticed the positive comments that were quite regular in our daily stand-ups:
"I had a really great meeting about how that system works ..."
"The developers got together and now we all feel really good about building the new widget ..."
"The BA produced some great diagrams that made the requirements much clearer ..."
Every time it happens, it's a little boost to the team members, and helps keep up the motivation of the team in general. I particularly remember a comment about my diagrams, and it made me feel good :)
It wasn't until it was pointed out to me this week by somebody on my team that I realised I wasn't really contributing to the positivity myself though. People do notice - and in ThoughtWorks, they will tell you too!
So my resolution for next week is to try and say something positive and complimentary at least twice a day (n.b. "nice haircut" does not count). Try it - it's easier than you think!
On the storyboard for my current project, the project manager has pinned up photos of all of the team members. Each team member's picture is stuck on to the story they're working on, and there's a space for people who are on holidays. I'm not sure how common this is at ThoughtWorks - given that this is my first project :) - but this is something I'd not seen on projects before.
I think it's cool, and it's useful too. It's helped me remember who's who, having joined the project halfway through, and it's easy to see who's doing what (instead of initials). It made me feel like a real part of the team when my photo was added.
Sometimes the little things can really make a difference :)
"I don't know what server to use for the new branch ..."
"CruiseControl is down ..."
"The base build is broken ..."
It sometimes seems to me as though the team use Scrum as an excuse not to have to solve their own problems. Broken build? Server stalled? No problem - holler "IMPEDIMENT!" and the ScrumMaster will come and sort it out for you.
What happened to self management? An impediment that's reported to the ScrumMaster should be something that you can't fix on your own. Many times a few probing questions helps the team member figure out the next steps ("Have you tried rebooting the server? Have you asked X if she knows the answer? Have you emailed team Y to see if they can help?") and nine times out of ten it is something they can do on their own.
Maybe teams feeling pressure to deliver their Sprint commitments feel that they haven't got the time to spend resolving impediments as well. Or maybe the same issues occur over and over, and they get frustrated (in which case, the ScrumMaster should be engaged to help solve the underlying cause).
The ScrumMaster, however, is not a general dogsbody - neither do they have the skills to fix every problem. To be successful, ultimately the team have to figure out how to support themselves as much as possible. The ScrumMaster needs to remind them of this as well!
Maybe it should be added to the team rules as a reminder ...
I've been taking a long break from blogging, but I'm finally back! I wish I had a fantastic excuse, like "I've spent a year travelling around the world", or "the dog ate my keyboard" but sadly the lack of blog has been mostly down to a lack of inspiration and motivation.
So what's changed now? you might ask.
The main factor is that I've just joined ThoughtWorks - a company well known for their work in Agile. Oh, and apparently some of their people can be a little opinionated too (I should fit right in!) I'm hopeful that in between working hard on a bunch of new stuff, I might find the time and inspiration to keep the blog going this time.
I can't promise anything great. It's going to be a bit of a cocktail of agile posts, general work stuff and some personal bits all thrown in. Mmmm, cocktails ...