Skip to main content

Avoiding Time-Wasting Pitfalls in Agile Estimation


If you do Scrum at work, you might be very familiar to the estimation in Planning 1. My PO has once complained to my team that why it took too long for estimating just a story. Wasting time results in the planning timebox is violated.


I give you some advice from my experience:

Estimation is estimation, not measure.

When you read some requirements, you see some risks but you actually don't know how complicated it will be.  Don't try to influence the others by explaining how to do it in too detail. Just keep in mind that you know the business domain pertaining to customer needs and estimate how much effort you will spend for it. The effort should be compared to your baseline one that you use for a simple requirement.

The bottom line is we do "relative estimation", not absolute estimation. For example, you are asked to estimate the height of a building. Basically, you just need to answer "how many times higher is the build than your height"; you don't have to give a accurate number.

Don't waste time for convincing the estimation points these are nearly the same.

Playing planning poker in Planning 1 somehow is interesting, but you should be careful. In many cases, you need to explain why your number is different from the other members (the largest number or the smallest one). If the different is very much (for example, between 3 and 8), the worth explanation is necessary. However, most of members have the same number excepting few members, the team don't need to force them to prove why they choose this number. For instance, there are 7 members in your team. Only two members choose 5 points and the rest of members choose 8 points; then your team just goes with 8 points. The exception case is only when the person has a strong concern and she wants to clarify it.

The main point is that you don't need to influence other members by proving how difficult to implement the requirements; these points should be discussed in Planning 2. What a waste of time if the team discusses too much about how to do the use story in Planning 1.

References:

[1]. http://www.slideshare.net/ScrumBreakfastVietnam/hcm-scrum-breakfast-agile-estimation-story-points
[2]. https://www.meetup.com/Scrum-Breakfast-Vietnam-Agile-and-Scrum-Meetup/events/233057237/

Comments

Popular posts from this blog

Think like a Engineering Manager

Off-boarding Members can leave the company for various reasons, and as a manager, it is important to take action. Hoping for the best is not a strategy. In the case of a low-performing member, I can kindly issue an official warning, set clear objectives for improvement, and re-evaluate the results. If there is a conflict between members, I need to be mindful and go beyond the situation to list our expectations with corresponding actions. Finally, if a member has a big chance to grow at another company, I can have an honest discussion with that member about the trade-offs. Balance at Work As an engineering manager, it is important to balance involvement in meetings and getting your hands dirty on some topics. The goal is to become a companion to teams. Here are my two actions to deal with the situation: Dedicate time for important-but-not-urgent tasks and prioritize them daily. Categorize work into four lines including management, project support, OKRs, and self-study. Management Conduc...

How to apply Lean - Kanban for your business

This is the topic of Scrum Breakfast meetup this time, speaker: Ms. Phuong Bui - Technical Project Manager of YOOSE Pte. Ltd. http://www.meetup.com/Scrum-Breakfast-Vietnam-Agile-and-Scrum-Meetup/events/230313727/ Lean comes from Lean manufacturing is a method that focuses on elimination of wastes. In other words, this is a set of principles for archiving the quality, speed and customer alignment. The first time I knew about the term "Lean" is  from the book Software Craftsmanship . Sandro recommends if we want to transform our pet projects into a real business, we should get familiar with Lean Startup concepts. In this talk, Ms. Phuong pointed out some major wastes includes information (ex: unclear requirements), processes (ex: waiting), physical environment and people. Knowing what the problems should be the best way to eliminate them. The difference between  Single item flow and Batch processing is the second main point; and it is the Lean's idea. Batch pr...

Applying pipeline “tensorflow_embedding” of Rasa NLU

According to this nice article , there was a new pipeline released using a different approach from the standard one ( spacy_sklearn ). I wanted to give it a try to see whether it can help with improving bot’s accuracy. After applying done, I gave an evaluation of “tensorflow_embedding”. It seemed to work better a bit. For example, I defined intents “greet” and “goodbye” with some following messages in my training data. ## intent:greet - Hey! How are you? - Hi! How can I help you? - Good to see you! - Nice to see you! - Hi - Hello - Hi there ## intent:goodbye - Bye - Bye Bye - See you later - Take care - Peace In order to play around with Rasa NLU, I created a project here . You can have a look at this change from this pull request . Yay! When I entered message “hi bot”, then bot with “tensorflow_embedding” could detect intent “greet” with better confidence scores rather than bot with “spacy_sklearn”. The following are responses after executing curl -X POST loc...

Books Read in 2022

My bookshelf Technical - Operating System: Three Easy Pieces. Andrea Arpaci-Dusseau, Remzi Arpaci-Dusseau. - The Effective Engineer. Edmond Lau. - English Grammar in Use. Raymond Murphy - Mythical Man-Month, The: Essays on Software Engineering. Brooks Jr., Frederick P.  - Peopleware: Productive Projects and Teams (3rd edition). Tom DeMarco, Timothy Lister. - A Philosophy of Software Design. John Ousterhout. - Modern Computer Architecture and Organization: Learn x86, ARM, and RISC-V architectures and the design of smartphones, PCs, and cloud servers. Jim Ledin. Thought Provoking - Đúng Việc. Giản Tư Trung. - A Brief History of Time. Stephen Hawking. - Một đời như kẻ tìm đường. Phan Văn Trường. - Một đời thương thuyết. Phan Văn Trường. - Tinh hoa xử thế - Dám bị ghét. Kishimi Ichiro, Koga Fumitake. - Phép màu để vượt lên chính mình. Nhan Húc Quân. - Scouting for Boys: A Handbook for Instruction in Good Citizenship Through Woodcraft. Robert Baden-Powell. - Thay Đổi Cuộc Sống Với Nhân ...

Separate Constructing a System from Using It

I n the real world, in order to use a building (hotel, supermarket, etc) we need to construct it first. This concern should be applied for software development as well. Step by step, I would like to show you the issue about no separation of constructing and using it and then I'll give you some approaches to overcome this issue. | Note : you can find the  below  demonstrated code here    Take a Look the Following Simple Application Used tools and technologies: Eclipse (Mars), JDK 1.8 I had an App which uses Controller . Controller uses Service (an interface). Finally, Service has one concrete class is DefaultService . //package vn.nvanhuong.system.separationconstructing; public class App { public static void main(String[] args) { Controller controller = new Controller(); controller.doAction(); } } public class Controller { private Service service; public void doAction(){ System.out.println("doAction in Controller"); getService().execut...