High level estimate for any project

Posted 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 🙂

Outsourcing: what i learned

Posted Leave a commentPosted in management
  • Describe scope better and split it to milestones. The more you have them the better
  • Involve Team and PO while selecting a contractor
  • Let teams directly communicate  between. Managers are bottleneck
  • Don’t use hourly rate! What you care about is how much you are ready to pay for certain group of features. Make contracts based on milestones not hourly rates
  • Make sure your contractor is agile and is applying best development practices (or similar to yours) in their daily work

Everything looks obvious, but sometimes you need to make mistakes by yourself to learn something 🙂

How to split user stories

Posted Leave a commentPosted in management, personal improvement

split user storyThis topic is always a problem. And main thing is not about user stories, but about achieving the common     understanding of things among team members, product owner and stakeholders. That’s why it is important to find the best way how stories should look like and how to split them in case if they are too big and ambiguous.

Common story problems:

  • Stories cover too much
  • Stories have too much dependencies
  • Stories do not clearly explain what user wants

Splitting stories lets us separate the parts that are of high value from those of low value, so we can spend our time on the valuable parts of a feature. (Occasionally, we have to go the other way as well, combining stories so they become big enough to be interesting.) There’s usually a lot of value in getting a minimal, end-to-end solution present, then filling in the rest of the solution…

While browsing an internet i found some great link about this:

How do you improve the accuracy of Product Backlog estimates?

Posted 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


How do you ensure that commitments are delivered?

Posted Posted in management

It is always hot topic while discussing project management approaches. I want to review this issue from Agile/Scrum perspective and my own experience.

If you are familiar with Scrum, its essence is:

  • The Team is given clear goals
  • The Team organises itself around the work
  • The Team regularly delivers the most valuable features
  • The Team receives feedback from people outside it
  • The Team reflects on its way of working in order to improve
  • The entire organisation has visibility into the Team’s progress
  • The Team and management honestly communicate about progress and risks

This way of working is based upon values of self-respect, respect for others, trust and courage and Scrum Master is responsible to make sure that the Team accepts and applies these values.
So, as you can see close Team’s and Scrum Master’s collaboration is very important in order for the Team to meet its commitments.

I made following important from my point of view notes for myself during Scrum adoption and apply/highlight them during each Sprint Planning or Sprint Retrospective session:

Keep the sprint scope clear and understandable for everyone: each Team member, Scrum Master, Product owner
Scrum Master must ensure that after Sprint planning meeting everyone leaves the room (or any other place) with clear vision and understanding of what needs to be done at the end of the sprint. There must be no surprises to anyone in the middle of the sprint or what is worse during sprint review. Each team member must understand following things: what features will be implemented, how they will be implemented, what modules/projects will be affected, how they will be tested and what are acceptance criteria’s. (You can read more about Sprint planning here)

Avoid ambiguities
All ambiguous requirements should be avoided from Sprint backlog, since as my experience shows it always leads to undone work and commitments failures. And this results to reduced team’s morale. The Team must identify such features/stories. Ambiguous requirements can be handled two ways: include it to sprint as optional task for additional technical analysis; such requirements are good candidates for Backlog Grooming/Estimation meeting. Both decisions must be communicated clearly among all interested parties. (You can read more about Backlog Grooming meeting here)

Commit to the “right” amount of work
Getting the commitments right is a learning process for the Team. The Team members need to learn that they have committed not only to scope by the end of the sprint, but also to quality (expressed through the definition of done), and that quality has precedence. Sometimes it is useful to categorize stories as ‘Committed’ or ‘Conditional’. The latter are generally smaller stories which have been authorized by the Product Owner and which the Team might complete if time permits.

If a committed story is not finished, then the Team and Product Owner discuss the situation during the Sprint Demo. Conditionals are a bonus. If the Team can finish one or more, that’s great, but there is no expectation that they will be completed by the end of the Sprint. From the perspective of expectation management, it is important to consistently deliver all ‘Committed’ stories, preferably with a ‘Conditional’ or two. Better to slightly under-commit and slightly over-deliver than the other way around.

Keep the scope fixed through the sprint
The Team and Product Owner must “freeze” scope for the specific sprint. Scope “freeze” can be formalized or verbal (it depends on situation), but it is Scrum Master’s responsibility to make sure that scope is not changed or additional work is not introduced during the sprint. Also I admit that trade off’s between planned features/stories and new features/stories are possible, but don’t use it very often, these must be exceptional situations – keep the scope freezed!

Keep the Team’s focus on sprint goals
Sometimes team members tend to lose focus from sprint goals due to different reasons: spend too much time on looking for the best technical solution, stuck with technical difficulties, consulting other team members and etc. It is not a problem that these things happen during the sprint, but sometimes teams try to use these as excuses during failure. Scrum Master must track such things during daily stand up meetings and make sure that focus is kept on sprint goals. (You can read more about daily stand up meetings here)

Keep the Team’s focus on quality and other non-functional requirements
Scrum Master must always remind the Team, that goal is not only to deliver desired functionality, but provide results with good quality and compliant with other non-functional requirements. Developers tend to forget about testing and results verification.

Always introduce automation if applicable
It is hard to believe but there is always a lot of room for automation: testing, builds, data preparation other activities. Automation helps to save a lot of time and focus on more important tasks. New Teams will always tell you that it is not possible, do not believe them – it is not true. Automation is possible and worth; it only depends on how much time you plan to invest into it. If Team is “afraid” of automation there is one rule that worked for me – start from easiest/the most obvious thing to automate (attract “automation experts” from other teams if possible), and after the Team sees the value of this automation they will always find ways how to automate other things by themselves.

Feel personal responsibility
Who is responsible for a story/feature implementation? Should it be whole Team or a particular person in the Team as well? Fundamentally, the Team commits to the story, but I prefer to have one team member take responsibility for each feature/story. This team member feels responsible for it and will probably demo it at the Sprint Demo, so s/he makes sure that it works its way through the process from accepted to done. This decision of course depends on culture, but sometimes there is a situation – if everyone is responsible, and then no one is responsible. But in any case each team member must feel personal responsibility for results.

Learn, inspect and adapt!