-4

How Spill overs can be reduced in agile projects I had seen lot of sprint in which the spill overs are very common though the estimation done is very proper.

closed as unclear what you're asking by jmort253 Jul 23 '13 at 0:42

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Welcome to PMSE. Please improve your question by making it more targeted. Make sure that you include information about your current process, and that you clearly identify what you're trying to achieve. It is also a good idea to note what you've already tried or considered, and explain why those things don't work in your situation. – Todd A. Jacobs Jul 22 '13 at 14:22
  • Pretty simple really, commit to half as much work. – Andrew Clear Jul 23 '13 at 9:39
1

There are two problems here:

  1. There should be no spill-overs. In a Scrum development team you would/should approach the product owner if you think you're not going to achieve what was agreed during the prioritisation meeting and re-negotiate the scope of the Sprint.
  2. If developers are routinely getting the estimations wrong then there is a problem with the estimation process and this needs to be resolved.

Estimations can go wrong for a number of reasons:

  1. The task the developers are estimating against is too big (I want an application that does X as opposed to I want some functionality). If the item being estimated is too big then it needs to be broken down.
  2. Developers need to do team estimations. This is a process where the whole team estimates items and agrees, as a team, how long a task will take. We do this because the time taken a senior member of the team may be significantly shorter than the time taken by a junior member of the team. A really good way to do team estimations is to use a Planning Poker tool (there are free ones on the web).
  3. The developers don't fully understand functional requirement. During estimations it is really important to ensure that the developers understand the item they are building.
  4. There are outside constraints (other teams, other systems, etc) which have not been taken into account.

Using a planning poker estimation system gets the whole team involved in estimations and will allow for better estimations.

0

The problem here is that you are working in a complex and uncertain subject domain ... technology. It rapidly changes, there are many complexities and often not well documented. Requirements change as people formulate new opinions.

First is to stop pretending, this is the real world and accept it. The next is to learn to deal and manage it.

The core agile principle to deal with this is

INSPECT / TRANSPARENCY / ADAPT

  • You have identified the problem of "spill over". Next is to inspect it; and I would seriously doubt it that the team estimates at the time of estimation is wrong.

  • Then be very transparent about the problem, as this makes awareness about it and it helps set the attitudes of everyone to change. Again, I would say its more organizational and management and not Team.

  • Find way to adapt and make changes to improve your situation. If you keep doing the same thing over and over and expecting a different result, that's insanity. (Einstein)

  • Next it is an ESTIMATE, so why are you treating it as ACTUAL.

  • Why has the management team not factored in the risk "What happens if the teams estimates are wrong?". I don't see this as a team problem, but more of a PO or management fail.

  • -

Not the answer you're looking for? Browse other questions tagged or ask your own question.