Full Transcript
https://www.youtube.com/watch?v=M9_z0WVwKK8
[00:00] In this video, we'll discuss what is the #NoEstimates movement, how it came into existence and whether we should consider it while estimating user stories or not.
[00:07] We will also discuss how to estimate user stories in the story map that we created in the last video, how to create baseline or reference stories, an easy to use the bulk estimation technique that I accidentally discovered while training and Agile team.
[00:20] And finally, what are some of the common mistakes that teams make while estimating user stories?
[00:26] Hey Friends!
[00:29] Welcome back to the channel.
[00:30] If you're new here, my name is Vibhor I am an Executive, Agile & Leadership Coach based in Toronto, Canada.
[00:34] And this is the 10th video in an ongoing series where I'm trying to simplify the process of planning an Agile product, starting with product vision followed by product roadmap release plan, finally learning how to create product backlogs full of effective bite-sized user stories.
[00:47] So if you're a scrum master or an agile coach, you consider subscribing to learn some actionable and super effective ways to be Agile.
[00:54] There are time stamps available.
[00:55] So feel free to skip around the video if you feel like it.
[00:57] But for now, let's get started.
[00:59] Estimates have always been an integral part of the software development process.
[01:02] By estimating the amount of time, money and effort required to reach project goals and outcomes developers and team leads can help managers and clients better predict budget and meet project goals and objectives.
[01:13] At least there's the theory behind the widespread and often unquestioned use of estimates in the IT industry today.
[01:19] But should we even be estimating our user stories?
[01:23] In the year 2012, most popularly known as the year of Armageddon, a software developer who goes by the name of Woody Zuill, disrupted the software and Agile community, when he shared a rather inconspicuous blog post on Twitter and tagged it with the popular, #NoEstimates, hashtag.
[01:37] That tweet divided the Agile community into two camps.
[01:40] The camp that thinks that Agile estimates are essential.
[01:43] And the camp that believes in the opposite.
[01:45] The #NoEstimates movement led by Zuill himself, gain traction because of the controversial suggestion he made about eliminating estimates all together.
[01:53] Zuill used his blogpost to detail the success of a project completed without estimates.
[01:58] When faced with a seemingly endless requirements document and asked for estimates on implementation Zuill and his team took a somewhat
[02:06] revolutionary, but basic approach.
[02:08] They identified what they consider to be the most crucial story in the document, broke that story down into smaller tasks and executed those tasks as quickly as possible.
[02:16] Once they showed the client, the initial win in the form of working software, the client was less concerned with estimates and more willing to let the development team continue delivering the features out of the to-do list.
[02:27] Zuill's team shifted their client's focus from estimating time worked to actually doing the work.
[02:31] And from projecting costs to cutting costs by simply diving in and getting down to business.
[02:36] The #NoEstimates camp made four bold claims.
[02:39] First estimates are always inaccurate and therefore pointless.
[02:43] The #NoEstimates camp who believes that when developers are asked to estimate the amount of time and work required to complete a project, they're asked to predict the future in a way that can't possibly account for the complex factors involved in completing the work.
[02:56] The second bold claim states that estimates are part of the software development process not because estimates are effective or beneficial, but because they have been part of the process for so long that developers, managers, and team
[03:07] leaders assume, that they are a necessity.
[03:09] The third claim is that developers, often pad estimates with buffers encouraging mistrust between team members, managers, and clients.
[03:16] Which can potentially harm project transparency and even damage healthy working relationships.
[03:21] The fourth and the last claim is that estimates are a waste of valuable time.
[03:25] Instead of beginning, the work developers are forced to spend time and money creating estimates that aren't even accurate to begin with and are therefore useless.
[03:33] Now this video is not about #NoEstimates, so I won't go deep into the argument favoring either Estimates or #NoEstimates.
[03:40] But just so we have a closure, here's what I think about the whole shenanigan.
[03:44] As an Agilist, I do not take sides or get attached to ideas that are set in stone.
[03:48] Now don't take me wrong.
[03:50] The four claims that I stated earlier do make sense.
[03:53] But we can't deny the fact that businesses do need estimates, especially in cases where they need to justify the spending.
[04:00] For example, the projects that are based on tranche based funding.
[04:04] At the same time, there are also cases where businesses do not need estimates.
[04:08] So from an Agile perspective, both extremes, those who say we should never estimate, and those who say we should always estimate are actually, well for the lack of better words, WRONG!
[04:17] These extremes, in my opinion, do not reflect the way the world works.
[04:21] So instead of arguing whether we should estimate or not, we should find ways that can help us figure out when we can use estimates to benefit business, and when we can do without estimates and save time.
[04:31] For example, in cases where businesses need to figure out the annual budgeting cycle to allocate money to different projects, estimation makes absolute sense.
[04:38] It's like going to an online travel site and getting estimates for various destinations to figure out which travel destination will best suit the family's travel budget.
[04:47] You absolutely need that kind of estimation.
[04:49] On the other hand, in a dynamic market experiencing explosive growth, like in the case of startups, there may not be much value in estimation because what they're doing is just releasing functionality as quickly as possible on very short turnaround cycles.
[05:04] Now that we have established that we need to be Agile when it comes to estimating or not estimating user stories, let's see how we can estimate user stories.
[05:11] If you're following this video series for some time, you know, that I have touched upon the concept of relative estimation in a previous video on prioritizing the initial product backlog.
[05:20] If you haven't already watched that video, a link to it is in the description or in this corner, if you're watching this on YouTube.
[05:26] So when it comes to estimating, in Agile we believe in refining our user story estimates progressively.
[05:32] Now, if you remember, when we created our initial product backlog and prioritized it, we used t-shirt sizes to estimate our epics and features.
[05:39] And this is because at the level of epics and features, we didn't have access to the more detailed and granular information.
[05:45] We were still at the ideation level, and therefore we used an estimation technique that didn't need excessive amounts of information.
[05:51] We then prioritize the initial product backlog, broke the features down into smaller user stories, and created a story map.
[05:57] With each of these steps of redefined user stories, with more details and a higher level of granularity.
[06:02] Now we may even have another level of precision beyond this.
[06:05] For example, during sprint planning, meeting the team breaks the user stories down into tasks.
[06:09] So think about estimation as getting progressively refined.
[06:12] Getting progressively more detailed, getting progressively more precise as more information becomes available.
[06:18] And the release plan level that we are currently at, we have enough information to move into what we call the story point estimation.
[06:24] But before we estimate our user stories, let's see, what are the prerequisites for story point estimation?
[06:29] The first prerequisite is the Definition of Done.
[06:32] For those who are not familiar definition of done or, DoD, as most people call it is a quality checklist that all user stories of a product, project, release, or sprint must pass before they could be declared as done.
[06:45] If you don't currently have a definition of done or stage entry or exit criteria, as we call it in Kanban, that we can use as a team to decide what kind of technical practices or quality checks we need before declaring user stories has done, them, well, you need one.
[07:00] The definition of done is one of the critical artifacts that keeps the team producing, working software to high quality standards.
[07:07] Here are a few things to note about definition of done.
[07:09] Number one.
[07:10] Definition of done is exclusive to each development team.
[07:14] You can't actually copy another team's definition of done.
[07:17] Number two, definition of done is not the same as acceptance criteria.
[07:21] Acceptance criteria are specific to each user story, and since it is unique
[07:25] to a user story, it doesn't transfer to another user story in the backlog.
[07:29] On the other hand, the definition of done is a single list that applies to
[07:32] all the user stories without exception.
[07:35] Here's an example of a definition of done.
[07:38] The developer has unit tested the functionality.
[07:40] All acceptance criteria have been met.
[07:42] Regression tests have been completed and code I've been
[07:45] reviewed by another developer.
[07:47] Of course, this is oversimplifying for the sake of education.
[07:51] Or is it?
[07:52] The second prerequisite for estimating user stories is having a baseline or a
[07:55] bunch of reference stories that the team can use as benchmark for new estimates.
[08:00] So let's see how we, as a scrum masters and agile coaches can help our teams
[08:05] create a bunch of reference stories.
[08:07] We'll be using the story map that we created in the last video.
[08:09] But if you don't have a story map, just use your prioritized product backlog.
[08:14] Looking at the story map, the first thing you do is ask your team to
[08:17] select five stories that the whole team can align on, in terms of complexity, risk and required effort.
[08:24] You then ask your team to rank the stories on a scale of one to five in terms of, number one complexity, which includes things like times to research, analysis, planning, and collaboration or communication required with people outside the team or with different departments.
[08:38] The second criterion that feeds rank our stories on is risk or unknowns.
[08:43] This includes dependencies, rework, fixing defects, incorporating stakeholders feedback, as well as time spent waiting to be able to do the work.
[08:52] The third criterion is the effort.
[08:54] Which, as we all know, is the time required to code test and validate the code.
[08:59] Once the team gets busy, ranking the five selected user stories, you can go and fetch yourself a coffee.
[09:04] Just kidding.
[09:06] Or am I?
[09:07] After the team is done ranking the stories, ask the team to sum the complexity, risk and effort values for each story and arrange the 5 stories in descending order of the sum, with the larger story at the top.
[09:20] Something like this.
[09:21] The next step in creating the reference stories is to look at the ranked stories in the reference table and assign them a story point using the Fibonacci scale.
[09:28] To start, we can either pick a middle story for the team and assign it a five on the Fibonacci scale.
[09:34] Or we can ask the team to self-organize and pick the middle story themselves.
[09:38] However, in my experience, I have found that picking a story for the team and giving them a headstart, especially when the team is new is much easier.
[09:46] Quicker and less stressful.
[09:48] Once you have a middle story, you then ask the team to select the next larger story and assign it a story point, comparing it to the first five point story.
[09:56] This could be the same five points or a larger number on the Fibonacci scale.
[10:00] We then do the same with one smaller story and assigning it a story point as well.
[10:04] Continuing this estimation assignment process will give us our first five reference stories.
[10:09] You can have as many different stories as you want.
[10:11] Five is just what I recommend.
[10:12] Now that we have our reference stories nicely ranked and estimated in our reference table.
[10:17] Let's quickly estimate the rest of the stories in our story map.
[10:20] Now, if you're familiar with Planning Poker, which by the way, I will cover in absolute detail in a separate tutorial series on user stories, you might come to me and say, Vibhor this will take a few days to estimate.
[10:32] Especially if you have a larger, more complex story map.
[10:34] Not the one that we are using as an example for educational purposes.
[10:38] And to that, I would say yes, you're right.
[10:41] Using planning poker to estimate hundreds of user stories, may take a lot of time.
[10:46] The good thing, however, is that we don't have to use Planning Poker.
[10:49] There are many bulk estimation techniques available that we can use to quickly estimate large number of user stories, or at least a portion of what is required for the upcoming release.
[10:58] Let's have a look at one such estimation technique that I accidentally created while training a team on Affinity Estimation, which is one of the popular bulk estimation techniques.
[11:08] The modified Affinity Estimation technique that I created is called SwimLane Estimation.
[11:13] And here's how it works.
[11:17] After I was done recording the whole video, I found that the microphone
[11:21] died in the middle of the recording.
[11:23] Now I'll have to go to everything again.
[11:25] All right.
[11:25] Let's get back to it.
[11:27] We use the reference table.
[11:29] The one that we use to create our reference stories and treat each row in the reference table as a Swim Lane for different sizes of user stories.
[11:36] We then ask each team member to silently pick a story from the story map, one by one, and put it in the appropriate Swim Lane, that they think is the right size for that story.
[11:46] The team members can also move stories between swim lanes.
[11:49] If they believe that the last person didn't put the stories in the right lane.
[11:52] As scrum masters and agile coaches, we keep an eye on such user stories, which move more than two times, keeping them separate, so the team can revisit and discuss them in detail later.
[12:01] Now, after the team is done, putting all the stories in the proper swim lanes and done discussing all the controversial user stories, we can use this estimator story map, to plan our release, which we will discuss in the next video.
[12:14] Okay.
[12:14] Now that we have estimated our user stories, that let's take a look at some of the common mistakes most teams make while estimating user story using story points.
[12:23] Mistake, number one, converting story points, to hours.
[12:26] Now I have seen a lot of teams converting story points into hours.
[12:29] The reason why it is not recommended is that doing so removes the benefit of relativity, committing everyone to the number of hours, providing a false sense of accuracy.
[12:39] Plus it is more challenging to reach a consensus among team members when aiming for a specific number of hours, versus a range, as in story points.
[12:47] Mistake, number two, Averaging Estimates.
[12:49] Now let's say for example, your team members are in disagreement on estimates for a particular user story.
[12:54] Half of the team thinks it's a three pointer and the rest believes that it's an eight.
[12:59] When this happens, most teams try to meet in the middle to resolve the conflict and assign the controversial user story, five points, sweeping the undiscussed details under the rug.
[13:08] If you, as a scrum master, see this happening, try to encourage your team to discuss the opposing viewpoints and the outlier estimates.
[13:15] Letting each person explain the reason for their assessment will rendered greater clarity and understanding of the work involved.
[13:22] Mistake, number three, adjusting reference story points every sprint.
[13:25] When the team adjust referenced stories, every sprint, the velocity of different sprints is no longer comparable making the team lose the historical velocity data, which is required to drive continuous process improvement.
[13:37] Mistake number four, existing story points based on whom it is assigned to.
[13:41] Now, you may notice from time to time that a user story is a three pointer for a senior developer and an eight pointer for a junior developer.
[13:48] Again, if you see this happening, try to get your team assign story points by comparing the user stories with reference stories.
[13:53] And not with the level of experience, individuals have.
[13:56] User story estimation can be a tedious exercise and can be especially difficult for team members who deal with stakeholders and executives on a regular basis.
[14:03] It is therefore essential to understand and make everyone aware that story points are just estimates.
[14:09] These can be well-informed estimates, no doubt, but still they are just best guesses.
[14:14] Like everything else in the world user story estimation and determining story points take practice.
[14:19] Each project and sprint is a chance for the team to learn and improve.
[14:22] As the accuracy of story points increase over time.
[14:25] So will your team's productivity and confidence.
[14:28] So there you have it.
[14:29] Now that you have an estimated story map, in the following video,
[14:32] we will finalize our release plan.
[14:34] Cutting the story map into somewhat realistic Will Haves,
[14:37] May Haves and Won't Haves.
[14:39] It'll also be the last video of this tutorial series.
[14:44] If you like this video, then give it a thumbs up, subscribe,
[14:46] and don't forget to provide your valuable feedback in the comments.
[14:49] I'll see you in the next video.