Story Points and Estimation

Story Points and Estimation | Atlassian Jira

Рет қаралды 6,894

Күн бұрын

In this #Atlassian #Jira video you are going to learn about story points and how to estimate them. Are you doing this right? How does your team do story points and estimation in your team? Story points and estimation can get very controversial. A lot of agile folks talk about the theory of agile, but few ever actually get into the details of how to actually use story points in an effective way. In this video, I try to explain the strategy that I've been using for years to help improve communication, effectivity, and overall results of my teams.
Learning the basics here can really help you down the road. Knowing how to find the information that is most critical to you and being savvy on where things are contained within the world of Jira are going to give you an edge over your teammates.
If you like this video, please make sure to give it a thumbs up. If you haven't already, please consider subscribing. If you have any questions about anything discussed so far, please feel free to make sure you leave your question in the comments section.
Jira Merch:
linkpop.com/apetech
Link to my other Atlassian Jira videos
• Jira Tutorials
Link to my Atlassian Live Streams:
• Jira Community Live St...
Link to Atlassian's Jira products:
www.atlassian.com/software
Link to my Fiverr profile:
www.fiverr.com/alexortiz924?u...
Link to my Upwork profile:
www.upwork.com/freelancers/~0...
Link to my personal website
www.apetech.me/

Пікірлер: 27

@ApetechTechTutorials Ай бұрын

To get more resources and get in contact with me check out this link linktr.ee/apetech

@michaelw2797 4 ай бұрын

Commenting to boost your algorithms as that's the least I can do to say thank you for sharing all this invaluable information.

@doris2988 Жыл бұрын

Thanks a lot, happy to be on your channel.

@ApetechTechTutorials Жыл бұрын

Thanks for being here!

@befullerton288 2 жыл бұрын

Enjoying and learning from your content! Thanks. IMO, there is a logical reason why the Fibonacci sequencing is so prevalent in Agile estimation. Each unit in an estimation sequence needs to be distinct from the others and Fibonacci provides not only the distinction but a clear and consistent scaling between units. If for example two units in the scale used were 99 and 100, there would not be a significant distinction between them and therefore the scale becomes less practical. However with units of 1 and 2 as estimation values, the team can say there is a doubling in the level of effort between those two work items. The latter is more helpful for the team then in distinguishing between the estimates and subsequently planning and measuring.

@ApetechTechTutorials 2 жыл бұрын

Excellent input/feedback.

@amolsharma9574 Жыл бұрын

Thanks a lot for such an information.

@ApetechTechTutorials Жыл бұрын

Hope you found it useful! Not a lot of folks give actual examples of how they use Story Points tactically.

@user-mm6gs1yw9f Жыл бұрын

I still dont see the merit for story points. We have something tangible to express effort and/or complexity. It is time. Sure, we can express the reason behind the time estimate with story points because it is the indicator for complexity. But it feels like we are creating an arbitary, fictional value to express something that has very little meaning or merit for a sprint. It might be an indicator that a user story might be longer than expected but is this information worth discussing and estimating on a regular base for every user story?

@ApetechTechTutorials Жыл бұрын

I think so. The concept behind the story is that it's supposed to be relative. You have to think of estimating software like asking an artist to estimate their time to complete a piece of art. It's hard to justify exact hours.

@dushyantbhardwaj0929 Жыл бұрын

I am doing it on hours, will strat now with SPs.

@ApetechTechTutorials Жыл бұрын

Hours can be tricky because it puts a lot of stress on the developers to predict something that is just untamable. Go with educated guesses and everyone wins!

@remain___ 2 жыл бұрын

Thanks Alex :)

@ApetechTechTutorials 2 жыл бұрын

Hope it helped!

@webagilepro Жыл бұрын

@@ApetechTechTutorials Extremely helpful. Thank you

@webagilepro Жыл бұрын

@@ApetechTechTutorials Does your story pointing technique including the QA testing effort or just the development (coding, unit, and integration testing)?

@ApetechTechTutorials Жыл бұрын

@@webagilepro It involves the developer portion of it. So, if your devs are QA'ing their own work, it should be included. If it's a different person, then I would say no as I would never want to be held accountable for someone else's performance.

@ApetechTechTutorials Жыл бұрын

@@webagilepro Thanks for the feedback!

@blueeyesblue9467 Жыл бұрын

Hi Alex, your videos are really educational and practical to me. So, I'd like to ask a few questions and look for advises. These are from real working environment and challenges. I am a tech lead of Windows system engineering team in a large banking company. The squad is responsible for architecture, design, engineering, PoC, pass internal review, deployment, maintain infrastructure, support other teams. We have been using time-based absolute estimation for two years. OK here we go. As a tech lead, I want to use the estimation best practice, so the workload and deliverable in planning can be more accurate. After writing up, I feel this is an Epic with 7 tasks, sorry. Looking forward to your feedback. - Yunpeng

@blueeyesblue9467 Жыл бұрын

Q1: There are many small tasks, mostly ad-hoc, say an engineer can finish within 2h. Let's give it 1 or maybe even 0.5 point. Then if we sum up so many such tasks, the reality and totally story points will be dramatically different. Because within half a day, one can finish roughly twenty 1m tasks (type A) but can only do two 2h tasks (type B), but both A and B are 1 point. My own view is, we can't use one type A task as reference task because it's too small, instead we must use ten type A tasks as reference. Glad to hear your thoughts.

@blueeyesblue9467 Жыл бұрын

Q2: There are some - not majority - routine deployment tasks or operation support tasks (maybe call it type C). We want to shorten the lead time, standardize them, make them flow and WIP, etc. Then type C tasks seem more suitable in a Kanban system. Then it looks like time-based estimation can be valuable to these tasks, but we just mix with other types of tasks in one team to handle.

@blueeyesblue9467 Жыл бұрын

Q3: Typically, many of our tasks cannot be handled in one focused timeslot. This is due to external dependencies, interruptions. So, we usually multitask, switch between those fragmented timeslots and task content. The real task handling periods often overlaps with other tasks for each person. I am thinking how we estimate. PO may argue why you can't multitask. But I think switching context also cause effort, people are not good at summing up small time slots, not good at converting this situation (or in their minds) to focused larger timeslot pattern. This means underestimation.

@blueeyesblue9467 Жыл бұрын

Q4: We have many meetings, partly due to culture, I guess. That's also one of the reasons I like Lean, 5s, Kanban and spent time to study them. As we are doing time-based estimation, we have to make buffer for the sprint, or add certain percentage to each task when estimate task time. How do you suggest we transform to relative estimation, given the team's dominant mindset is still time-based. To make the question more challenging😉, we are using story points to represent hour.

@blueeyesblue9467 Жыл бұрын

Q5: A follow up question of Q4. If we transform from time-based story point usage to Fibonacci, the metric is directly ruined, some historical data is not comparable. We may have to explain, if any management team member cares. I am thinking two options to make the transition: Option 1. map current story point value to new value for all task types, given a total point of 20 for each person of one sprint. Option 2. work out reference story for type A work, give points to two tasks of this type, roughly estimate the rest tasks because I don't think we (manager, SM, PO, tech lead/others) can work out many types B, C... soon, then we will be involved in endless discussion. Meaning "waste" and against MVP concept (Lean, 5s is more effective to analyze this scenario) to me. But to estimate the total of rest tasks, we need a given total point of 20. The 20 is just the number I choose between 13 ~21 as the warning line. Because we need a quick and effective way to make up the story points for majority of tasks (type B, C...) and keep them comparable with type A. Either way, we need some training to help the mindset shift, especially for management team.