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

My must-have apps for daily work

There is no doubt that cool apps can help us be more productive and enjoyable at work. For the time being, I really love the following apps which are used by me almost every day. 1. A personal Kanban In fact, a personal kanban is the most useful app for me. Why does it matter? It is not just a to-do list, but it keeps me motivated every day because it helps me be able to know what my "big picture" is. I usually set up my plans together with a path to reach them.  KanbanFlow  is my preferred tool. KanbanFlow 2. A terminal Needless to say, a terminal is a must-have app for every developer, especially the ones use macOS/Linux. Due to its importance, I love to decorate and enhance it to be super exciting with various tools such as  iTerm ,  oh-my- zsh , and  thefuck . ;) iTerm + oh-my-zsh 3. A documentation "ecosystem" As a developer, I can not remember all things that I have experimented a day. Moreover, a document is really useful for sharing an...

Monday vhandit #1

This is the first post in a series of articles called "Monday vhandit". You can go to the original post by clicking on each head title. Character encodings: essential concepts This article points out why Unicode matters and differentiates among concepts: character sets, coded character set (unit is code points), and character encoding. Explained from First Principles: the Internet The very structural and well-explained article contains almost concepts of the Internet. I really appreciated the author's effort put on that post. Dev Community - DevDojo I just joined this community. DevDojo is really a developer-oriented platform. It is very nice, easy, fast, and sufficient to write (Markdown supported) and search for a post. The best of it, you also have a personal blog for your posts at "<your_username>.devdojo.com". My username is vnnvanhuong Everything you need to know about HTTP security headers A good collection of HTTP security-related headers. Moreover...

Selenium - Override javascript functions to ignore downloading process

I have got an issue with downloading process on IE 8. This browser blocks my automatic-download functionality on my app so that I could not work with my test case any more after that. In my case, I didn't care about the file is downloaded or not, I just focus on the result after downloading process finished successfully. Therefore, I found a solution to ignore this process so that I can work normally. I use Primefaces, here is the remote command to trigger the download process <p:remoteCommand name="cmdGenerateDocument" actionListener="#{logic.onGenerateDocument}" update="xrflDocumentCreationPanel" oncomplete="clickDownloadButton();"/> The following is my test case: @Test public void shouldUpdateStep6ToWarningIfStep1IsValidAfterFinished(){ MainPage mainPage = new MainPage(); waitForLoading(mainPage.getDriver()); EmployeeDetailPage empDetailPage = new EmployeeDetailPage(); waitForLoading(empDetailPage.getDriver()); e...

My 2017 Review

Passion for System Design After finishing a one year project, my longest stable team (lasted for 3 years) was separated into two smaller teams. Sadly, but that was a good chance for me to become a key member in my new team. My preferred skills were about system architectures; therefore most of the tasks of building the application structures were handled by me. In order to enhance my design system skills, I have spent much my time for reading books closely after work. These following books help me a lot. - Object-Oriented Thought Process | Matt Weisfeld - Head First Design Pattern  | Elisabeth Freeman and Kathy Sierra - Java 8 in Action: Lambdas, Streams, and Functional-style Programming | Alan Mycroft and Mario Fusco Junior Technical Architect I was requested to join a technical architect team (aka Team. Alpha) where I actually had gained experiences almost on interviewing candidates for my company (lol). Besides, I noticed myself must improve the skills of convinci...