Skip to main content

How to get better in estimates

Last post 03:01 pm December 3, 2014 by Andre Noubissi
6 replies
12:27 pm December 2, 2014

Hi.
Just came to a new scrum team and notices that burn down graph in TFS always goes upwards at the beging of the sprint before it starts to burn down. I asked why and the reason - the new tasks are added at the begining even after the planning finished.It is reoccurring scenario for over many sprints and the team is used to this now.
How can we improve the situation?
Shall we spend more time planning identifying all the task in the beginning , or is this normal for the team to add more tasks as sprint progress.?
What do you recommend.?
Regards


03:04 pm December 2, 2014

My 2 cents...

In and of itself, adding tasks after planning is not an issue - and is a common occurrence. It may or may not be indicative of other issues- that depends on the particulars, of course.

In planning a team may diligently attempt to identify the work/tasks involved to deliver the PBI/story. Despite that best effort, actually getting into the work very often exposes what was unknown at the time of planning and tasks are altered/added/removed as necessary. I think that can be classified as 'normal' (and healthy).

On the other end of the spectrum, if the team is adding tasks because they brushed planning aside to begin with, that's something to address.


03:31 pm December 2, 2014

What is your goal here Roman?
have you asked the team how this affects them?

Is the way they are currently doing things working for everybody? Is the current way slowing them down? Is there a better way for them to work?

I've come to learn that sometimes I (as Scrum Master) think a problem exists, when in fact it does not exist and is bothering no one on the team nor is it slowing them down.


03:45 pm December 2, 2014

Sprint Planning doesn't have to be done in terms of tasks - that's just a common convention. What matters is that, by the end of the session, the team have a plan which is sufficiently detailed and robust for them to explain how they intend to create the increment. I


03:50 pm December 2, 2014

f they can't explain that to the satisfaction of the Product Owner then Sprint Planning has been inadequate.

The Sprint Plan is however expected to evolve during the Sprint, as a result of collaboration and the further clarification of requirements. As such, some of the constituent items (e.g. tasks) may be added or removed.


02:59 pm December 3, 2014

In my opinion, i think the first thing you should do here is to check if this always happen. If yes, then you should review with the team why this is happeneing.
This can really be an indicator that the sprint planning was not done properly. I mean i understand that it might happen that sometimes the estimation will be readjusted, but not always at the beginning of the sprint. If the dev. team starts with the sprint without a proper estimation, then they are somehow increasing the risk of not delivering all the selected PBIs.


03:01 pm December 3, 2014

In addition to the sprint planning, you could check how far your dev. team is allocating time to the backlog refinement (grooming) during the sprint.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.