I've spent the last few weeks condensing years of experience and many successful agile teams process into a concise and holistic guide which can be found here:

I've spent the last few weeks condensing years of experience and many successful agile teams process into a concise and holistic guide which can be found here: https://agileforleads.com/ https://agileforleads.com/ Here is my verbatim section entitled "8.3 Estimating a Story". Be sure to take take this in the context of the whole process and tooling, which is covered in detail in the ebook https://agileforleads.com/ https://agileforleads.com/ > Remember how I said that if you only take one action from this course to your team it should be the Retro? Well, the second most critical action to your #agileforleads process is the Estimation; specifically consistent and repeatable estimation. Sometimes this is called Backlog Grooming or Backlog Refinement. Those terms don't work for me because they suggest that it's kinda optional, and for us, it isn't. Other teams call it "pointing [a story]" and you'll see why below. Not every Agile process will be scientific. Many of the common agile patterns don't need to be. Scrum practitioners will generally apply the following but, as usual, I'm going to refine it a little more for you so that it's not only easier to use, but substantially more valuable. Don't get stressed or hung up on being careful to ensure that you pull off estimation activities "by the book" because I've said it's so important. Just carry these tips with you and try to throw a new one in each time and eventually, over time, you'll find a consistent groove. Being able to reliably predict future delivery rates based on historic delivery rates requires control. Controlling the inputs ensures more accuracy for the outputs. It's just science. The rules for our estimation are the following: * We use "points" instead of hours or person-days. Our points are a Fibonacci sub-set: 1, 2, 3, 5, 8 and "too big". * We use Planning Poker for "throwing down a number" and we use our hands to do it. Avoid apps and playing cards if possible. Like the Retro voting, we don't reveal votes until everyone has silently selected a number. Everyone reveals together. * When there is only a single size difference (eg. min is 3 and max is 5) we "go large" (select the 5). * Use all 10 fingers to indicate "too big" and as early as possible, break these down into 2 or more smaller stories. * When there is wider deviation, a "low ball" team member gives reasons for their low vote and the "high ball" member explains theirs too. Then discuss. * Limit discussions (strictly 2 mins if you have a lot of stories to estimate; use a stopwatch) and invite a second vote to zoom in on a number. Two, maybe three, rounds of voting should be enough to get to the same number or a single size difference. If not, split the story or create a Chore to investigate the requirements further. * Log blocking questions for the PO, update the AC/this is done when as you better understand the story, and add notes/reference links to the description while you're discussing the work. * Log the agreed estimate/points number at the end and quickly move on to the next story. Have a look at the following scenario and then after, I'll unpack some of the details. How-to: Simple Story Estimation using your hands Team estimation need not be a formal ritual. Two developers at a desk is enough. On other occasions where you want to move quickly through many stories (you've just cut up a large block of work and the PO wants a date), booking a meeting room with a bigger selection of your team gives everyone focus, and increases the accuracy of estimation. 1. Gather team members together. 2. Open up Tracker and expand the story detail (so the title, AC and any attachments/images are clearly visible) so everyone can see it. 3. Invite someone to read aloud the story and it's AC. Show larger views of attachments. Someone could summarise or add a little more detail verbally if that helps. 4. Ask members whether the story is clear enough on it's own for everyone to "pick a number" (silently). If not, ask and answer questions for a couple of mins and log questions down for the PO that the team can't resolve on their own. 5. When members "have a number", ask everyone to hold up closed fists and count backwards from 3 to reveal votes simultaneously. "3. 2. 1. go!" Single finger for 1 , 2 fingers for 2 , etc, 8 fingers for 8 and all fingers for too big . 6. Jen votes 5, Alex 2, Kate 3 and James 2. Since she's high, the facilitator asks Jen "why the 5?" 7. Jen, who got caught up seeing the css and js note explained a concern which the other team members quickly identified as confusion. Once the issue was clarified Jen exclaims "Oh! Sorry, I'm a 2 then as well". 8. Another member asks "So go large then?" 9. And the rest of the team agree. The facilitator logs 3 as the estimate and open up the next story. I know this example doesn't cover all the scenarios and variables but I'll try to cover many questions I hear frequently and some of the more common variations. * Let's start with story points. Developers are notorious at estimating very inaccurately when it comes to hours and days. Just ask any project manager. It's also a recipe for bias too - I want to show my team and myself that I have a handle on something and I can do it (quickly), so I'm mentally incentivised to offer a smaller than reasonable number. Most developers often estimate by a factor of 0.5 or smaller when using linear time. Points push all that to one side and free a technical team member to think more clearly. We usually say that points are in terms of "relative complexity or effort". Complexity works for some personality types. Effort for others. The other thing to note is that a 2 is not necessarily twice as much as a 1. Think of 1, 2, 3, 5 and 8 simply as containers. 5 is the "middle of the road" container and 1 is the smallest thing the team will ever do. In that "1 container" might go a one line change that takes 10 mins or a re-styling effort of 3 hours. But it's the smallest so the smallest items of relatively the same size get a 1. 8 on the other hand is absolutely the biggest thing any member of the team wants to commit to in an iteration. If your iterations are 1 week and Bob thinks the story can be done in a week but Sarah thinks longer, then it's more than an 8, and should be broken down. * Less tools is more. Avoid the Planning Poker cards and apps and just stick to your hands. This also influenced the selection of Fibonacci numbers. We don't use the size 0 because it's somewhat confusing and dangerous (like a Chore - more later). We don't use more numbers because you get diminishing returns by increasing the resolution of estimates too much further. Tracker also offers "t shirt sizes" S, M and L which I've found helpful for planning heaps of work up front very quickly but not particularly practical for day to day work or new teams to this process. * At all times, remember: we're just estimating. I'm preaching to myself here. I often have to remind myself that these are all just estimates. It helps you relax a little and not apply as much pressure to yourself (and your team mates) and sometimes get to a number quicker. * Use the Done column to reset your base of reference. I didn't include this in the narrative above because if you're estimating regularly (every 2-3 days), each team member subconsciously knows the relative scale of each point container. But on more occasions than not, it's helpful to pull up the Done column in Tracker and refresh the team on what each size means, using recently completed work: Scroll to the bottom of the Done column (most recent completed iteration) and work back until you find 1 or two of the various sizes that the team is debating match the container for the current story being estimated. This is another mechanism to ensure consistency over time for the estimation inputs. You're essentially reminding each team member "what a 3 looks like" or "what a 5 looks like" prior to each silently forming their estimate. This historic reference is vital in ensuring that work of the same relative size receives the same estimate over and over again. * PO does not vote. After a story is defined, the developers usually estimate it. Sometimes other members of the build team can help but this activity must absolutely exclude the PO. The PO has a conflict of interest when it comes to estimating how big a story is, so they need to stay out. If your PO can sit in on the discussion to answer questions and further clarify, then that can be helpful but I've found they often influence the estimate, sometimes simply by being present. If you can find a way to meet with the PO and clarify the AC separately and estimate without the PO, I think you will have more success. Discuss in your Retro if you have issues. This, like many practices, simply gets better over time. It's ok for it to be little slow at first. Like commits, stories, iterations and release phases, the smaller you can batch things, the faster you'll cycle and quicker you and your team will learn.