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/

How can scrum be made scalable?

Scalability of a process, network, or unit is its ability to adjust or adapt to any expansion. For example a central server is said to be scalable if it performs similarly when attending on either five clients or fifty clients. In Scrum, it means that the scaling mechanisms applicable for a single Scrum Team can also be used for larger projects with multiple teams.
Is Scrum scalable? Initially, Agile authors believed that Agile methodologies including Scrum was predominantly for small scale projects. This opinion was based on the fact that Scrum had not yet been applied on large scale projects. The Guide to the Scrum Body of Knowledge (SBOK™ Guide) gives comprehensive directions through which Agile methodologies including Scrum, can be scaled and applied on larger projects
When to scale? In small Scrum projects there is adequate scope for the self-organizing Scrum Team members to collaborate among themselves. The problem starts when team size expands and when there is coordination required between multiple teams. Scalability in Scrum can occur at three levels – Projects, Programs and Portfolios
How to scale? Scalability in Scrum is achieved primarily through the Scrum of Scrum (SoS) Meetings. Scrum recommends small teams; however if teams are larger it is recommended that they are divided into smaller teams who can meet occasionally to discuss their status.
What makes Scrum scalable? It is recommended that Scrum Teams should ideally have six to ten members. This does not mean that Scrum can be used only in small projects – it can be scaled to be used effectively in larger projects. If the size of the Scrum Team exceeds ten members, then multiple teams can be formed to work on the project simultaneously.
Scrum of Scrums facilitates synchronization between multiple Scrum Teams in larger projects. Team representatives update each other about team’s progress, challenges faced and coordination activities. Frequency of Scrum of Scrums (SoS) Meetings is determined by inter-team dependency, size of the project, recommendations by Scrum Guidance Body (SGB) and complexity level.
Scaling in Distributed Teams: Scrum recommends colocated teams and face-to-face communication between team members. This is often not possible, as companies have distributed teams working in parallel across geographies and time zones. For the purpose of scaling, in larger projects employing distributed teams, the Scrum of Scrum Meeting can be held using video conferencing, chats, social media etc.
The ‘Convene Scrum of Scrums’ Process is Facilitated by the Chief Scrum Master (or another Scrum Master). Representatives of various teams, usually the Scrum Master of individual teams or any other designated team member. For larger projects, involving a significant number of teams, multiple levels of these meetings may be convened. In larger projects, as it is difficult to have all participants together at one time, all important matters should be discussed
The Scrum of Scrums meeting is usually held at predetermined intervals or when required, to collaborate and track progress, address impediments and dependencies across projects. An agenda for the meeting can be announced in advance by the Chief Scrum Master, allowing individual teams to consider the items for discussion. Impediments faced by individual teams, likely to affect other teams should also be indicated. Issues, risks and changes likely to affect multiple teams should also be communicated during this meeting.
Achieving Scalability: Each team representative is expected to update other teams, usually in the form of four questions. (i) What has my team been working on since the last meeting?, (ii) What will my team do until the next meeting?, (iii) What were other teams counting on our team to finish that remains undone?, (iv) What is our team planning on doing that might affect other teams?
Result of Scrum of Scrums Meetings include Better Team Coordination facilitated coordination of work across multiple Scrum Teams, especially when there are tasks involving inter-team dependencies (as future tasks of one team may depend on the timely delivery of a task by another team). Discrepancies between work and deliverables are quickly exposed. The Scrum of Scrums is a forum where team members can transparently discuss issues and resolve them.

Scrum of Scrum of Scrums: In organizations that have several Scrum projects happening simultaneously, the Scrum of Scrums Meeting can be scaled up another level to a Scrum of Scrum of Scrums meeting. In this situation, a separate Scrum of Scrums Meeting is held to coordinate each group of projects that are directly related to each other.

To know more about it kindly visit :http://www.scrumstudy.com/blog/how-can-scrum-be-made-scalable/