Less common estimation methods use:
What if you provide a bad estimate?If a developer estimates far more hours for a task than are eventually spent on the task, their expertise may be put into doubt since the estimate was so inaccurate. In other words, it was a wild guess. At the same time, if a developer doesn't get the work done in the predicted time, she jeopardizes the customer's plans to release the product or new feature. This is business, and business is money. Few customers will be pleased with such a slip. In fact, that's why I don't like estimation — because sometimes it is super tricky to accurately determine the time required to complete a task.
How to make a time estimateAs a rule, estimates are made in hours or story points. My personal preference is to do the estimation process using story points. It's hard to be mistaken about concrete physical objects, but story points are a little more abstract. Software development teams typically provide estimates as amounts of time: hours, days, weeks, months. These time estimates are based primarily on personal experience, guesswork, and/or intuition. In this case, developers simply look at the task and express their assumption about how much time it will take them. As a result, these estimates are very rarely accurate, because there are too many factors that can affect the duration of the work. That's why many teams that use the Agile methodology also use story points. Let's dive in!
What are story points?A story point is a unit of measurement for expressing an estimate of the total effort required to implement a certain piece of functionality fully. That is, we're talking about relative complexity. Teams assign an estimate in story points based on the complexity of the work, the volume of work, and risk or uncertainty. These values are usually assigned to more efficiently divide the work into smaller pieces, thereby eliminating ambiguity. Over time, this helps teams understand what they can accomplish in a given period of time and helps them more accurately plan subsequent chunks of work. This may sound completely counterintuitive to you, but this abstraction is indeed handy: it pushes the team to make tough decisions about the complexity of the work. Let's take a look at some of the reasons to use story points when planning:
- You can avoid inaccurate time estimates.
- Unlike estimates made in units of time, story points let you account for overhead costs: communications between team members and the customer, various team discussions and planning activities, as well as unforeseen situations.
- Each team will estimate their work using different scales, which means that their capacity (measured in points) will be different.
- By defining a scale for assigning each story point, you can quickly allocate points without much controversy.
How NOT to use story pointsUnfortunately, story points are often misused. Story points can be misleading when they are used to assess people, define detailed deadlines and resources, and when they are mistaken for a performance measure. Instead, teams should use them to understand the scope/complexity of each task and to set priorities. Perhaps that the parts that are regarded as more difficult should be tackled first, so they can be done before the end of the sprint, possibly shifting easier tasks to later. Let me remind you what a sprint is in the context of the Scrum methodology:
The length of this time period is determined when development begins and is agreed between the team and the customer. This can be a period of two weeks or a month, or any other period. As a rule, the effort estimates are made at the beginning of each sprint in order to plan the work that can be completed by the end of the sprint, when the completed work is delivered to the customer.
|A sprint is a repeatable fixed time interval during which some planned piece of functionality is implemented.|
The demo helps you see your progress in developing the product, receive feedback from the customer, and adjust the project's trajectory according to the customer's vision. But we digress a little. Let's get back to estimates. It would be too subjective to have just one developer provide estimates for all the tasks. So this process is usually a team effort. There are quite a few techniques that teams can use to generate estimates. Today we will look at the most popular technique: scrum poker. This technique requires a manager who will act as a moderator for the scrum poker. This can be someone who is a scrum master or possibly a PM.
|When the work completed during the sprint is presented to the customer, we call that a demo.|
What is Scrum poker?Scrum poker, or planning poker, is an estimation technique that is based on reaching an agreement. It is mainly used to estimate the complexity of the work ahead or the relative size of software development tasks. I'll say straight away that scrum poker is a common software development practice, and you need to know what it's all about. It usually involves an app or website to facilitate a team's collaborative creation of an estimate for a particular task. How does this happen? The team takes something from the backlog (a new task, some functionality) and briefly discusses possible pitfalls and other nuances associated with it. Then each participant chooses a card with a number that reflects their complexity estimate. Oh, one more thing, when making these estimates, we use numbers in the Fibonacci sequence rather than ordinary numbers. Fibonacci numbers are popular in scrum poker, because there is an increasingly large gap between them (resembling the levels of a pyramid). Some tasks will be highly complex, and we won't be able to get away with a small number of story points. There are some unusual cards that have the following meanings:
Unknown number of endpoints
Infinitely long task
Need a break
- T-shirt sizes — S, M, L, XL
- Dog breeds — chihuahua, pug, dachshund, bulldog, and so on (personally, I think this is the strangest unit of measure for effort estimation =D)
Example of effort estimationSuppose your team established the following scale for assigning story points to estimates:
Scrum poker is played for each task, and you provide an estimate as follows:
|1. Do you have any experience with this kind of task?||+1 — I have done this task before||+2 — I have not done this task, but worked on a similar one||+3 — I have not done this task and have no experience with anything similar|
|2. Volume of work required for functionality||+1 — Small volume||+2 — Average volume||+3 — Large volume|
|3. Complexity of implementing the functionality||+1 — Easy||+2 — Average||+3 — Difficult|
|4. Complexity of testing the functionality||+1 — Easy||+2 — Average||+3 — Difficult|
- You have never implemented similar functionality before: +3
- The functionality is average-sized: +2
- The implementation will be highly complex: +3
- Writing tests for the functionality will be highly complex: +3
- He has worked with a similar task before: +1
- The functionality is average-sized: +2
- The implementation will be of average complexity: +2
- Writing tests for the functionality will be of average complexity: +2