A rant on estimation

This is a transcript of a team discussion we had around 'estimation', why we do it, what its for etc. The format for estimation is 'Relative Effort' using a fibonacci scale (1,2,3,5,8 etc). We had a team meeting to go over our estimation after we had 2 sprints with wildly different points delivered.

Transcript and outcomes we summarised by me, below (in a team Skype session)

Yes, the decision yesterday was to continue estimating, we just use certain estimates as triggers for further action, i.e. 5/8's are indicators that the story needs to either be preceeded by a spike, [Ed's note - this is a team decision, we have agreed within the team to try to standardise card sizes as much as possilbe, and our team standard was a '3'] or broken down if possible, we will try to get stories to be round about the same size wherever possible

No 2's as per current (team chose to drop 2's as they spent too long quibbling about whether somehting was a 2 or a 3, and this was deemed a waste of time and that estimation is a tool used to help business priorities, as well as us to visualise our sprint (to an extent) and that there may well end up being a range of 3's (much laughter about this) [Ed's note: At a subsequent retro, some team members observed that they had been under pressure to estimate everythings as 3's ]

Bottom line though, we need to be clear what the estimates at pre-planning/release planning are to be used for, as we can't (in 2-4 weeks) be held to estimates if product have used them to 'promise' delivery as in these are early estimates, not 'promises' and by product I mean YOU [Product owners name]..sorry need to stop using that term in the 3rd person

Essentially the team were a bit nervous that by providing 'number' estimates at this stage, they might be mapped to a previous sprint velocity and we might be held to a set of stories as a deliverable.

What we know about estimation is that we have seen swings within sprints, and that makes velocity a guess at best. Mainly we are indicating by estimating a story as a 3 that we are comfortable with the size and complexity of that story, that it along with some others is doable within a 2 week sprint.

A 5-8 point estimate indicates sufficient doubt in the story (unknowns) to conclude whether it is achievable without significant risk of its delivery within a shorter sprint, and that this story either needs breaking down, or a spike prior to commencement to reduce the unknowns

Comments

Post a Comment

Popular posts from this blog

Experience report: Building an offshore agile team in India - The Australian perspective - Part 1

Experience report: Offshore agile teams – An Australian in India’s perspective Offshoring software development, in this case, using agile as a software development methodology contains many opportunities to learn. These kinds of teams have specialised requirements both in the technical realm as well as social expectations on the individuals hired. A lot of organisations have tried, and failed in a lot of cases, to set up independent agile teams in India . With the right approaches and expectations set, Aconex has shown that it is possible to successfully set up agile offshore operations as we did. To get your offshore program on a sustainable footing you’ve got to understand the market and be prepared to be responsive to local conditions. What sort of people are/were we looking for? A simple explanation would be, agile software engineers and product people with a desire to work in self managed, highly collaborative teams. We use the terms ‘passionate, self-starter, indep
Read more

Using an agile storyboard as a scale of certainty

Image
As per my previous post, In my current team we have started using a 'Just in Time' (see how I feel weird about saying Kanban, not sure why yet) approach to doing various activities around development. Mostly this is around planning, but in that sense, we are also doing as much Just inTime as possible in giving an estimate. Scene setting We are a team that does 2 week sprints, but we also don't do a major release at the end of each sprint. We tend to wait for 5 sprints to pass before we do releases, there are a number of organisational reasons for that, but suffice to say, thats the way we do it around these parts. Our story wall (in ugly table form) The table below is a basic representation of our Story wall. As you can see, for the story wall, we deliberately do not just focus on the current 2 week sprint. We also have columns heading beyond the current sprint to encapsulate the entire release timeline (in this case the team have already completed two sprints so their are
Read more

Building agile teams in India: Part 3 - challenges at the hiring stage (especially for a fresh face in the market)

Part 3: Constraints/Challenges of building a ‘boutique’ agile team in Bangalore/India (especially if you’re an unknown in the market) Low brand recognition In India, brand is seen as really important for a lot of candidates even in 'considering' an organisation. Family recognition of the organisation is seen as very important to candidates, acceptance of the organisation by candidates parents is often a key factor. There is also evidence that candidates enhance matrimonial chances by joining a known brand, I've even had conversations that dowry can be increased dependent on the name of the company.  All of this leads to an uphill challenge for smaller organisations, however: The candidates that do join you are joining because you've sold the company culture and challenge well, which increases loyalty/retention. Also, working on brand building is shown to pay off over time, hence partly an answer to the question of “Are you ready for this to take ‘x’ ye
Read more