Sprint Planning Minus Estimation Efforts

This week Product School Slack's community members uncovered ways to properly plan product sprints. Check it out!

SudeepAug 1, 2021, 6:48 PM

Hi there, is there a way to do the sprint planning without doing the effort estimate for each ticket ? Don't you guys think that effort estimation is very time taking and tedious work ?

DanielAug 1, 2021, 11:47 PM

One thing to keep in mind is that Story Points are meant to be a measure of complexity, not a measure of effort.

A junior dev and a senior dev will have different levels of effort for the same item. The complexity remains the same.

You can simply stop estimating the complexity. It's useless. At the point in time where an item is in your backlog, and you feel confident that it's been descoped and broken down as small as possible - it doesnt matter what kind of complexity it attracts. If it's the most important thing to drive business impact at that time, you damn well are going to do it.

There has been a growing No Estimates movement for quite a few years now. Do a bit of googling, and feel comfortable in dropping estimation from your rituals. Priortize on impact and if use your gut when planning. If it feels 'too much' in a spint, then don't add so much. If you complete the work committed in the sprint early, simply take the next item in the backlog.

Yuting ChuAug 2, 2021, 2:59 AM

Hi , interesting insight. Can you post a link to the source where story points are meant to be a measure of complexity and not effort?

I have the book User Stories Applied - is it in there?

How are you doing the story point estimate? It’s not meant to be time consuming or tedious

markAug 2, 2021, 5:26 AM

To add to Daniel- it’s complexity, effort, and unknowns (but most people think it’s time)

I once had a data scientist ask me, why the weight of two tasks at 1 and 2 points isn’t equal to that of 3.. interesting think to think on. Time is something we’re all taught so it’s easy to think that quickly.

Thought the purpose of using points is to measure the tasks being handed out so we don’t hand out too much. Ideally we’d get everything done but really it’s to say this is a “big” task cuz it’s complex or there’s a lot we don’t know etc or a small and simple task because we know what we need to do and it’s not a high effort (etc)

Uday VyasAug 2, 2021, 7:36 AM

Hi Sudeep, Completely agree with Daniel and Mar. So, in my exp. as a Project Manager, I have followed the following:

..Not Sure how to add tables here..

Uday VyasAug 2, 2021, 7:40 AM

Did you enjoy this conversation? Join the #1 Slack Community For Product Managers

Join our private community to network with over 90,000 PMs.
Explore our industry-leading Slack channel, and discover for yourself how it became the most expansive community of Product Management across the world:

Weekly AMAs: Every week we host ‘Ask Me Anything’ sessions with top PMs in the industry. This open Q&A forum gives you the most impactful insider access to all your Product questions.

Resources: Specific and dedicated channels for all of the most important topics in product: #05_ask-for-help, #07_resume-review, #08_job-portal, #10_feedback-n-surveys, #11_product-launches, and more!

Careers: Searching for a career change? Or looking to get your foot in the Product door? Our Slack channel has daily job openings in Product that are posted by Product leaders looking for new qualified PMs to join their teams.

Network: Connect and network with Product people from your city or country in our local channels (#local_sanfrancisco, #local_europe, #local_singapore, and more!)

Join here https://productschool.com/slack-community/

To learn more about Slogging, or to partner with Hackernoon and add the Slogging Beta app to your Slack community and create beautifully crafted & curated Hackernoon drafts, visit Slogging.com