Monthly Archives: May 2015

The most Controversial Concept in Agile Delivery – Estimating in Story Points

3 Replies

This blog post is another one of those that I should have written a while ago as the topic of story point based estimation keeps coming up again and again. To really understand why story point based estimation is important for Agile delivery, I think I need to explain the idea behind it.

The purpose of estimates is to get a good idea of how much work needs to be done to achieve a certain outcome. To do that, the estimate should be accurate and reasonably precise. This is where the crux of the problem is: precision. If I’d asked you how long it takes to fly from Sydney to Los Angeles, you would not respond with an estimate that includes minutes and seconds because you know that it is ineffective as it is not precise. The more precise we get in estimates, the more we pretend to be able to do something that we cannot do: work at that level of precision. The other downside of precision is that each level of precision requires more work to be put in the estimation process. I have done many IT projects and can tell you that my estimates for each individual task is off by as much as +/- 100% easily, but in aggregate my estimates are pretty good.

Let’s explore the difference between accuracy and precision a bit further:

accurate vs precise

It should be clear that we care more about accuracy than we care about precision and that is exactly what story points do for me. I am spending just the necessary amount of time estimating to be reasonably accurate without trying to become too precise. The usual Fibonacci sequence (1,2,3,5,8,…) helps to avoid false precision as well. Now, to be honest we could call it 1,2,3,5,8 days and be done with it as that would probably achieve the same outcome as story points. The problem is that for some reason we are a lot more tempted to use the other in between numbers when we talk about days. We are also tempted to equate days of effort with schedule, and most of us can attest that a day of effort is hardly ever done in a day of schedule as we get distracted, multi-task or attend meetings. The story point concept provides us with a nice abstraction that prevents these mental shortcuts and keeps us focused on the relative nature of the estimate.

The other thing that should be obvious is that a day of effort for one person is not the same as a day of effort for another person. More experienced people need less time than more junior people, so any estimate in hours or days is flawed unless you know who will do it. Story points do not suffer from this problem as they are relative to other stories and independent to the person performing the tasks associated with it.

The other nice thing with Agile estimation is that it usually is a lot closer to the often recommended Delphi technique, which asks multiple independent experts to estimate tasks and then aggregate it. Planning poker is a pretty close approximation of the Delphi technique and is therefore much more accurate than estimates done by individuals.

But why do we need a point system at all, why do we not just do relative sizing in t-shirt sizes or something similar. As I have explored in another blogpost (link), teams need a goal line whenever there is a certain outcome to be achieved. The easiest way to do so is by tracking progress on a numerical scale (see Agile reporting post). And if you work in a larger organisation you probably want to have some common currency to be able to measure the throughput (see productivity blog) and be able to swap stories between teams. Here I will go with the guidance that SAFe provides, start with a point being roughly a full day of work and estimate everything else relative to that. On a regular basis bring members of the team together to estimate an example set of stories and use this process to recalibrate the relative understanding of size.

So what if things change? One thing that people are always concerned about is scope creep or inaccurate estimates. For a story by itself I don’t have strong opinions on whether or not you update the size once you realise there is more or less work than expected. However, if you use larger buckets for your initial estimates (e.g. a feature that should roughly take you 100 pts), then I think it is important to measure how many points the stories of that feature actually add up to – if that is different to 100 pts in this case you have some real scope change that will impact your timelines.

To close off, I will provide a few helpful links to other comments/blogs about story points which you can use to learn more about this topic:

http://www.scruminc.com/story-points-why-are-they-better-than/

http://collaboration.csc.ncsu.edu/laurie/Papers/ESEM11_SCRUM_Experience_CameraReady.pdf

http://www.mountaingoatsoftware.com/blog/seeing-how-well-a-teams-story-points-align-from-one-to-eight

https://www.scrum.org/Forums/aft/564

http://www.mlcarey321.com/2013/08/normalized-story-points.html

http://blogs.versionone.com/agile_management/2013/10/14/scalable-agile-estimation-and-normalization-of-story-points-introduction-and-overview-of-the-blog-series-part-1-of-5/

Mirco’s Advice for supervisors – Feedback, the best way to improve your team

3 Replies

adviceAfter discussing one-on-ones in my last blog about tools for supervisors, this blog will focus on feedback. Feedback is your opportunity to improve the performance of your team on a daily basis. Here I am talking about ongoing feedback you can give your team every day, not the kind of feedback you give once a performance year. Before I get to feedback let me remind you that this post is one in a series of six posts on tools for supervisors:

  1. One on Ones (link)
  2. Feedback
  3. Coaching (TBD)
  4. Delegation (TBD)
  5. Principles for success (TBD)
  6. Pitfalls for supervisors (TBD)

While one-on-ones are probably the most important practice given the impact it has on your team, feedback is what moves your team forward. The most important point about feedback is to never give feedback when you are angry. The way you communicate and what you say when you are angry will undermine the overall idea behind feedback – to make your team more effective in the future. There is nothing you can do about the past, move on and provide constructive feedback. You should only give feedback when you are able to smile while doing so. This will make sure that you are in a positive frame of mind.

There is a good reason to be in a positive frame of mind when giving feedback. If you think about it, how often is a mistake made on purpose? – it hardly ever is. So assume good intent. There are very few people who make mistakes on purpose. This of course means that there is no reason to get angry, just try to help your direct-report become more effective by pointing out the ineffective behaviour and discussing alternatives. I will tell you how to do that further below.

Let’s not forget that you should also give positive feedback. Some tend to forget this even though it is so much easier to give positive feedback. For it to really make an impact, make sure to be specific about positive feedback as well. Don’t just praise “Well done”, but rather give specific positive feedback like “When you prepare meeting notes and send them out before I even ask you, it helps everyone stay on top of their assigned tasks. Thank you.”

Purpose: The purpose of feedback is to encourage effective behaviour in the future. There is no “why” in feedback, which means you are not trying to understand why something happened, but instead trying to encourage effective behaviour in the future. This is not a root cause analysis. If you take this purpose to heart you will see that there is little difference between positive and negative feedback, you simply state what your direct-report did, the impact it had and what to do in the future (either continue or change behaviour).

How to Do: Feedback is not easy to give, especially negative feedback. The key here is to focus on the behaviour and not implied traits: e.g. “When you raise your voice and make sarcastic comments” is much better than “When you act like a jerk”. Make sure the person you give feedback to understands the implications, e.g. “When you send me your status on time, it allows me to collate the report quickly and be on time for my report to my boss”.

Don’t argue with your direct-report about either the reason for his behaviour or the validity of your feedback. Remember the purpose of feedback is to influence future behaviour. If he argues with your feedback, walk away, he will either do the same thing again and you can give him the same feedback again (this time with one more piece of evidence) or he won’t do it again (which means your feedback has achieved its purpose). The guys at manager-tools.com refer to this as “shot across the bow” and this piece of insight was eye opening for me and made me avoid so many unnecessary and ineffective discussions with my direct-reports.

There is a specific format that you could use to give feedback: Ask first “Can I give you some feedback?”, then focus on behaviour “When you do x, this is what happens”, and then either thank him and encourage him “Thank you, keep doing this” or ask for an improvement “Can you do this better/different next time?” Timing of feedback is also important, don’t give feedback on things that happened longer than a week ago. Consider feedback like breathing, many supervisors hold their breath and then blast it out after a while (or even just at the end of the year), try to breathe regularly. Small bits of regular feedback will allow you to keep correcting course and not try to turn the whole ship around twice a year.

One last piece of advice: Find a way to encourage yourself to give feedback frequently. Put a reminder in your calendar every day to give feedback, put a comment on your one-on-one tracking sheet to provide feedback, or do what the guys at manager-tools recommend: Put 3 coins in your left pants pocket and every time you give feedback move it to the right pocket. At the end of each day you know whether you gave 3 pieces of feedback and each time you put your hands in your pocket you get a little reminder of how you are tracking.

Sure ways to fail #2 – Not knowing what the goal is

1 Reply

“If you don’t know where you going, any road will take you there” – The Cheshire Cat in Alice in Wonderland

The_Cheshire_Cat_by_JTwilight97This quote from Alice in Wonderland is very insightful and I have quoted it many times when talking about strategies and plans. In this case I want to use this as an illustration for a way an Agile project will surely fail. If you don’t know what the goal line is for a specific release or sprint, you have no means to understand how you are travelling and whether you are on the right track. I have seen many teams post great velocities in their first couple of sprints, but when asked whether they can achieve the release goal they have no idea. This is painful and leads to a lot of anxiety for the team and stakeholders.

How does this happen? I believe that this is due to the fact that in Agile we don’t want to spend too much time planning and estimating too much to the future and hence start kicking off projects really quickly. We do this with just the first one or two sprints worth of stories ready for implementation and then we keep grooming the backlog. This is great, but if you choose to do so, I think you need to spend a little bit of extra time to give the team a final goal. You don’t need to have all the stories for the release, after all we want to be flexible in Agile, but you should have some idea of the things you need to deliver. This can be stories, themes, epics, features or whatever you choose. At this stage you should do a quick estimation to provide the overall scope for the release and a goal line that the team can use in their burn-up graphs (read more on reporting here). You can then track changes to the goal line if epics require more stories than expected or if any new scope is introduced. This allows the team to have meaningful discussions with the product owner and the stakeholders about required changes to the release. If you don’t have such a goal line, you could get a shock surprise towards the end of your release and surprises are not something we want with Agile delivery.

The one caveat is if you work in a project that truly does not know what the scope is or the scope is undefined. What you can do in those cases is either work in a Kanban style or with an assumed target velocity. If you work in Kanban you only ever have to worry about the first few items in your backlog and set expectations with your stakeholders on how long they will take and then do the same for the next set of stories on a regular cadence. This requires a lot of trust between the team, product owner and stakeholders. Alternatively you can set yourself a certain target velocity and just work towards that and fill the velocity with stories that are getting groomed on an ongoing basis.