Estimating User Stories and tasks and KPIs

Why are you asking your team to estimate in certain units? What problems are you trying to solve by asking them to collect certain data?

As a Scrum Master, I don't believe that you should be telling your team how to go about their work, which includes what data to gather or what reports to produce. Instead, my advice is to start with the problem and then work with the team to solve them. Perhaps gathering this information can help solve a problem, but there may also be other ways and the team should be the one to look at the options and decide which solution(s) to try.

What essential metrics KPI I can show them at the end of the Sprint.

Isn't that rather late in the day? Wouldn't it be better to use metrics and measures, such as burndowns, throughout the Sprint, so the team has transparency over its progress towards the Sprint Goal?

as a Scrum Master I asked my team to estimate the User stories in Story points ans task and sub-tasks in hours. 

Why? What is the purpose and usefulness for this? I'm going to put this quote from the section of the Scrum Guide that describes the Development Team here for you to contemplate (emphasis added by me)

Development Teams have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

This quote from the section that describes the Scrum Master seems relevant as well (emphasis added by me)

The Scrum Master serves the Development Team in several ways, including:

• Coaching the Development Team in self-organization and cross-functionality;

How do those statements relate to what you have asked your team to do? 

@Ian Mitchell points out the correct use of metrics.  They are not something you look at after everything is done, it is something you look at constantly in order to assess your abilities to meet the goals you have in place.  In Scrum, the Sprint Goal is paramount. 

@Thomas Owens points out the real reason for using metrics.  They are to help you identify for improvement and remediate issues that the team is having in delivering incremental value. 

There are metrics that many teams use long term to help them identify issues.  There are metrics (often the same mentioned before) that helps a team determine if they have properly addressed issues. These metrics should be used for specific purposes and to assess the consistent ability to progress towards the goals of the team. 

Thanks for your replies, in that case can you please advise me what should I do in terms of coaching them Scrum and Scrum Values

1. When they have no idea of what SCRUM is and what is task estimation. By using estimation in Story points they can do right planning having an "Average Velocity" after 3-4 sprints.

2. One of my team members that has experience working with Scrum proposed that they also estimate their tasks and sub-tasks in hours. I just wonder what is the reason behind this and if doing this can generate any valuable report or data for the future.

3. The point that really interest me is that how effective is viewing Burndown chart in the middle of the Sprint when all the User stories are being completed "DONE" at the end of the Sprint. 

4. It is a bit difficult to me o understand how I can coach them all of these Estimation, BurnDown, Velocity without any practice? I suggest the, they agreed )).

Hi Anahit,

 

1) If they don't know what Scrum is, you can make a workshop in order to make them understand the values, principles and all. For the estimation, you can make a small workshop. Velocity is just a measure to help the team to see how much they produce, why do you think it should be in story point ? why not in T shirt size or even hours ? The story points are used mainly in order not to give the illusion of false promises. But it is not the only way.



2) Inspect and adapt. Try hours, try points let the team decide.



3)  Is the point of a Sprint to make all the stories or to reach Sprint Goal ? The Burndown help seeing during the Sprint if the Dev Team is deviating a lot from the original assumption made during the Sprint Planning. 



4) you can facilitate workshops to coach/teach them how to do. 

1. Do not try to teach them everything at once.  Give them an overview of the Scrum (not SCRUM) framework that will let them see the entire process.  Then pick 1 or 2 things to start focusing on.  I would suggest that the Daily Scrum and Product Backlog refinement be the first.  As part of refinement, let the team experiment with ways that they feel will help them better understand the Product Backlog Items.  Stories and Story Points are never mentioned in the Scrum Guide. And the word "velocity" is never mentioned. 
   
   
   
   The intent is for the Scrum Team to find a way that enables them to fully understand each Product Backlog Item, have a way of predicting their ability to deliver, and ensure that they are doing enough work each Sprint to support the Sprint Goal while delivering a potentially releasable increment of value.  
   
   
   
   Your statement of "By using estimation in Story points they can do right planning having an "Average Velocity" after 3-4 sprints" is false.  As the team matures, their estimations will improve and become more aligned across the team.  So if your team establishes a "velocity" of 24 story points after 4 Sprints, it is very likely that by Sprint 6 they will have changed their estimation practices and that velocity will change.  Remember that refinement is to enable the Scrum Team to have better understanding of the items in the Product Backlog.  The better that understanding, the easier it will be for the Development Team to pull a group of items into a Sprint Backlog that they will have confidence in being able to complete in a Sprint timebox.  
2. Did you ask that team member why he felt it was useful and how the team he previously worked with found it to be beneficial?   My opinion is that an estimate should be simple to understand.  If you are estimating on multiple levels in different units, how easy is that to understand the estimate? I would also caution the use of hours estimates because they are often turned into a weapon against the developer. "You have said it would take you 3 hours but you continue to work on it after 6." is too often said when using hours.  Another downside of using hours is that the developers will start to look at their estimates and say "I only have 60 hours of work planned for an 80 hour sprint. I need more work." then find that they misunderstood something and underestimated so that now they are overloaded.
3. The idea of agile in general is to complete work as soon as possible.  If your burndown chart shows a steady line across the top and then a sharp drop on the last day, you may want to discuss with the team if items could be broken down smaller or if maybe it would help to have multiple people work on items instead of each team member working on 1 item alone. Finishing every Sprint Backlog Item on the last day of the Sprint doesn't give the team a chance to ensure that the entire increment (the complete body of work done during the Sprint that supports the accomplishment of the Sprint Goal) is functional as an integrated body of work.  Is that a practice that they want to continue?  Discuss in the Retrospective if they feel it is a problem and if they have ideas of how to improve it.  Use the quality of the Sprint Review as input to that discussion. 
4. If you study and understand the principles of the items, it will be easier for you to coach.  Remember that there "is not a right way to do this".  The right way is what works best for the team using them.  But if you don't understand the principles of each item and the benefits that they can provide, then you will have a difficult time helping others.  Take each thing one at a time and research it. Ask specific questions about one thing at a time in this forum so that you can get focused opinions to help you understand.  Have the team participate in the research and discovery of how to best use artifacts to help them. It could be that the burndown chart is the wrong thing for your team and instead using Aging of Work in Process and Cycle Time graphs would work better.  Research, experiment, inspect and adapt.  That is the agile way. That is the empirical way.  That is as close to the "right way" that you will ever get.