Better Task estimation

Scrum Teams often fixate on Sprint planning, particularly the estimates Even as Team members protest about spending too much time in meetings, and they’ll wrestle over individual task estimates. Let us quickly recall the reasons why we do this activity. We estimate tasks in order to

1. Develop an attainable team pledge to deliver an assured amount of Customer value, articulated as User Stories selected for the Sprint
2. Track the team progress through a sprint through a Burndown chart. This is extremely important if we do not want “Type-A Stakeholders” leeching the time of the Core Team.

Part of the reason for decomposing User Stories into tasks is to develop more accurate estimations. Each step of the decomposition will convey some awareness in the higher level and is used by the Scrum team to familiarize with their prior estimates and use this retrospection to develop their upcoming estimations. Without this estimation, the team is not well informed and cannot improve. The organization needs reliable information for predictable planning for marketing activities. So how does one estimate Tasks effectively?
A Good Scrum Master should start by allowing the Sprint planning meeting to take its own course, irrespective of the time it takes, until the Scrum team can establish steady velocity. The Product Owner should however, make sure the team’s deliverables pass the test of creating potentially shippable deliverables each sprint. When the team self-organizes and the project has attained constant velocity, the Scrum team will be competent to make, and meet sprint pledges based only on verified velocity and their estimates of Story Points. Some Scrum Masters may want to continue enabling this freedom as a good Scrum implementation.
The Scrum Master should then start focus on the Burndown chart. The Sprint Burndown Chart is a graph that depicts the amount of work remaining in the ongoing Sprint. This chart shows the progress that has been made by the Scrum Team and also allows for the detection of estimates that may have been incorrect. The initial Sprint Burndown Chart is accompanied by a planned burndown. It begins with the sum of all the tasks for the ongoing sprint. The Sprint Burndown Chart should be updated at the end of each day as work is completed. If the Sprint Burndown Chart shows that the Scrum Team is not on track to finish the tasks in the Sprint on time, the Scrum Master should identify any obstacles or impediments to successful completion, and try to remove them. For best results, the Scrum Master should insist that the task breakdown results in the smallest possible tasks. The burndown chart reveals the estimated work effort left. This works best if there are lots of small tasks, typically ones that require a day or less to do.
The Utility of the task estimation is improved if there are numerous small tasks in the Sprint Backlog. This is because the daily updates of the task estimates are more current. Burndown chart for large tasks would be unresponsive on a daily basis, because progress on the large tasks would not show up for multiple days until a task was completed. Thus the remedy is to make tasks small. Ideally, a task should be completed in a day or less.

 To know more click on: http://www.scrumstudy.com/blog/

Tips for First time Scrum Master

Most new Scrum Masters have a rudimentary comprehension of their new role. Many have undergone training and received their Licensed Scrum Master designation. They are thrilled and keen to don on their mantle of a Scrum Master in the event their teams invite them in formally. Once their initial enthusiasm starts fading away, a troublesome hesitation begins to take shape. Daily, in the midst of paying attention to and smoothing the daily standups, a quiet thought begins to flow in the Scrum Master’s mind:
The role of the Scrum Master is a difficult one for a number of reasons, not least of which is the fact that they have no authority; in fact the Scrum Team can fire them. Scrum Master is an expression misconstrued so quite often, sometimes consciously, which causes misunderstanding. The appellation itself hints people to unseemly assumptions because of the attachment of the term ‘Master’. Some consider this person is in reality the administrator of the Scrum Team or a synonymous term used in place of “Project Manager” in Traditional Project manager frameworks. One approach used when adapting Scrum is to redefine the role of the managers and convert them into the Scrum Masters for their respective Scrum Teams. In reality, Scrum Master is not giving the orders, neither the expert, nor the intermediary, or the negotiator. Scrum Master is not the administrator of the Scrum Team and without doubt not the project manager under an innovative label.
The Scrum Master has four key duties:
• Facilitation of the stakeholders and interfaces
• Agent of change within the organization
• Impairment remover
• Remover of distance between business and development
Many people who take on the role of Scrum Master have to be, to some degree or other re-trained into their new role. The Scrum Master is a servant-leader to the Scrum Team.

A Scrum Master should embolden, encourage, challenge, intercede, interrogate, pay attention and perceive in equal quantity toward making the rest of the Scrum team as effective as possible and altering the organizational environment to be more cooperative to Scrum framework. Ultimately Scrum Master is inconsequential in the Scrum process because he/she neither is making the payment for, nor in receipt of, the product. Scrum Master should understand his/her part therefore as a facilitator. Those who are openly involved in production should come to the deductions they need to forge ahead. Every now and then, this is quite easy and the Scrum Teams recognize the answer but essential to be inquired a few unpretentious questions to comprehend this. Usually, it really is a multifaceted situation where not one person knows what the solution is and the best the Scrum Master can do is to search options before The Scrum team decides on the best answer for that time. Occasionally, it is essential to fail in order to find a better way. A Scrum Master may have to find techniques from diverse fields – thinking, inquiring, advising rather than directing – to be useful in her endeavor of Scrum Master.
to know more visit-http://www.scrumstudy.com/blog/tips-for-first-time-scrum-master/