High level estimate for any project

Posted on Leave a commentPosted in management, quick thoughts

Set up a dart board. Each point on the dart board represents $1M (1-20). The rings represent the following:

  • The bulls eye is $100k
  • The ring around the bullseye is $300k
  • The next ring out is .6x
  • The outer ring is .8x

Take three darts and aim for the bullseye. Average the scores of the three shots. This is your “high-level” estimate for each project.

p.s. originally read it somewhere and found it reviewing my notes 🙂

Largest impediments

Posted on 1 CommentPosted in management
Have you ever thought about the largest impediments while working according Scrum?
I personally encountered following largest impediments with teams i was working.
Story points and relative estimation
We realized that it is very difficult to separate time and size while making estimates for specific tasks. Another problem related to this issue is trying to be very specific while estimating with story points. This led to a lot of misunderstandings at the start. It’s quite difficult to realize that duration of implementation might differ for both tasks estimated as the same size. 3 is not equal 3 !!! 🙂
The very first team’s impressions was – How can it be?! So, it led to a frustration at first. But one thing helped us a lot – we made an analogy to simple physical formula: V (speed) = S (distance) / T (time)
We agreed on meanings for formula’s elements. 

V is team’s velocity and it can change over time. We can go faster or slower which depends on situation – someone i sick, we face a lot of impediments and etc. Team’s goal is to achieve constant/predictable speed.

T is our fixed sprint time box (2 weeks)
S is size of our features that we want to estimate. It’s a common thing to measure destination in meters (Europe). So team’s goal was to identify “our” meters, to make it easier we took some already implemented tasks as standard for our measures.
Analogy with meters also helps to explain why 3 is not equal to 3. Imagine that someone asks you to measure a distance from your home to work and lake nearby. You might say that it is about 9 km to both destinations, but when you measure actual distance (traveling the distance/taking item into development) you identify that distance to you work is 8,5 km and distance to the lake is 10,1 km. So, initial estimates are not equal, they only help you to have an understanding of size!
After we applied this rule several time it became very easy to estimate by story points. Btw, we used Fibonacci.
Agile (not only?) development practices
I mean automated testing, integration testing, developers do testing, and etc. Why “not only?”, well i think these practices are applicable everywhere.
Our quality reduced dramatically during first sprints. It should have been expected result since we were developing more than we were actually able to test and verify. Developers refused to test. It led to very simple thing – while one feature was developed another stopped working.
It was a nightmare, team started to blame Scrum, we couldn’t finish product backlog items properly, everybody was disappointed.
We did the following. We reduced speed (velocity) and dedicated some time for test automation and integration testing. The team was surprised how much value it gave them. They were able to detect problems in advance and in no time. It was a break through, team saw the value and they started to apply automation everywhere they could. And developers do testing, but in a different way.
Communication with other teams
I faced very interesting problem at very early stages of applying Scrum – people started to avoid helping other teams despite the fact that they are working for the same project. Team members were focused only on their own goals and they were afraid of doing anything else except what was planned in the current sprint.
This issue helped us to identify one simple problem – cross-dependencies were not identified properly by our product owners. We increased cross communication among the teams to be able to detect possible dependencies as soon as possible. Cross dependent items are included into the same sprint for several teams. Joint planning sessions and cross team short meetings are organized in a periodic manner (Scrum Masters can cancel those meetings if they are not relevant for the current sprint).
I again was curious what other people think about this topic and what impediment they have encountered. I started a topic on the scrum alliance group. You can read all the answers in details here

  • Writing good user stories – clearly
  • Let the developer do the estimates
  • Functional managers try to control their “resources”
  • Interference (intrusion)
  • Team contribution during sprint planning
  • Some members tries to force only their way.
  • One way communications
  • Estimating tasks with huge buffers
  • Management offers no time for the team to learn, with deadline pressure as the reason
  • Fear and habbit (no willing to change)
  • Misconceptions about Scrum
  • Contracts not adapted to Agile
  • User stories not completely “done” at the end of the Sprint
Do you recognize yourself here?

User stories – size of story points

Posted on Posted in personal improvement
How to improve estimation with story points?

Story size before sprint

  • Keeping stories small is very important.
  • Keeping them substantially smaller in size than the Sprint length is very important.
  • Keeping them about the same size is somewhat important.

Story size after sprint

  • When something takes /more time/ than estimated, there is learning
  • to be done. When it takes /less time/, not so much.

 

 

How do you improve the accuracy of Product Backlog estimates?

Posted on Posted in personal improvement

This time i want to share my thoughts about estimates. You can also read this book to get better insight on this topic – Agile Estimating and Planning by Mike Cohn.

There is one very important thing to keep in mind – estimates of size and duration needs to be separated. It helps to plan releases (schedule) with better prediction.

Very good article about life cycle of product backlog item can be found here.
Following activities from my point of view help to improve product backlog items estimates.

Product Backlog grooming meeting (reference)
It is very useful activity and it helps the Team and Product Owner to prepare for sprint planning meeting better and review/updates estimates of future backlog items. This Team estimation should take place regularly. We have a reserved planned meeting in the middle of each sprint. If changes occur or new product backlog items are available the meeting will take place, if there are no changes the meeting is cancelled to avoid waste of time. So, it depends on the situation and Product Owner together with Scrum Master makes a decision.

Product owner briefly presents product backlog items and the development team asks questions. If the global idea is understood the Team moves towards estimation. Some key points about the estimation techniques for teams.

Estimates are shared
Estimates are not created by a single individual on the team. Agile teams shouldn‘t rely on a single expert estimates, estimates are best derived collaboratively by the team, which includes those who will do the work. There are at least two reasons for that: First, we tend not to know specifically who will perform a task; Second, even if one team member estimates size as N story points other team member can remember some fact (problems, changes or something else) from previous sprints which was forgotten by this team member and estimate might be increased or reduced.

Deriving an Estimate
Analogy – estimates can be made by analogy. The Team can say: „This story is a little bigger than that story“. When estimating by analogy, the estimator compares the story being estimated with one or more other stories. It is much easier to estimate relative size rather than absolute size. Do not mix this approach with comparing to a single baseline; it is about comparing one story with another.
Disaggregation – split large stories or features into smaller and easier-to-estimate pieces.

Planning poker
It helps to improve estimates because of three reasons:

  • Planning poker brings together multiple expert opinions to do the estimating
  • Dialogue ensures that all opinions are taken into consideration while making an estimate and opinions are justified
  • Group discussion helps to pin point important things

After the size of product backlog items is estimated Product Owner can prioritize product backlog items later and re-schedule the release if necessary according the team‘s velocity or take other corrective actions.

Sprint planning and Daily Stand-up meetings
This is another level of agile planning which adds another level of precision. The Teams details their estimates of “groomed” product backlog items. You can read more about sprint planning meeting here.

If sprint planning session or results of the sprint identify that size of selected backlog items is different, Product Owner with the Team can review product backlog and make corrective actions: adjust velocity, change schedule, change scope or other.

The daily plan is the most precise, since each team member express commitments to complete (or make progress on) a task during a day. Tasks estimates are adjusted and reviewed every day by the Team.

Different planning levels
Estimates accuracy is improved due to different levels of planning – the release, the sprint and the current day. Such way of planning helps the Team views the project from different perspectives.

The iteration plan helps completing the highly coordinated work of a cross-functional team within short iteration. And the release plan helps the team to keep focus on more distant goals, since only short-term goals may be inconsistent with the desired long-term result.

Why does estimates accuracy matter at all?
People always want to be correct. They feel uncomfortable when are wrong and this happens due to different reasons: personal responsibility, team image on a company level, loose of trust from product owner/scrum master and so on. Motivation will reduce in general and it might lead to not desired results in a long run. But as i noticed the following thing happens first – inaccuracy will result in the team taking on too little or too much, both of which create inefficient story progress through the work queue. And as the result product owner will not be able to predict releases and what features can be expected.
Scrum Master must make sure that estimates are accurate and track the performance of the team.

Practical guidelines to improve estimates

  • Involve the whole team
  • Plan at different levels
  • Separate estimates of size and duration
  • Re-plan often
  • Track and communication progress
  • Learn and adapt
  • Plan features of the right size
  • Base estimates and plans on facts

„Planning is everything. Plans are nothing. “
Field Marshal Helmuth Graf von Moltke