What is your answer

What is your answer

The Product Owner on a project, on which you are the Scrum Master, has identified disaster situations, such as earthquakes and tsunamis, as potential risks to the underwater transnational communication sea link. The Stakeholders have suggested that steps to safeguard the foundations of the ocean infrastructure be taken at the earliest, and also have recommended that a contingency reserve be created, which could be used in case of disaster situations. This is an example of:

a) Risk Mitigation.
b) Risk Prioritization.
c) Risk Avoidance.
d) Risk Assessment.

Importance of priming the product backlog for value-added sprint planning

Preparing and maintaining the product backlog can be a very productive habit while getting engrossed during an agile project. In an agile setting, whatever the development team was working on each sprint draws the attention of the weekly and daily focus and quickly becomes integrated.

• Recognize that requirements charge up forecasting in agile

In agile, requirements drive planning. Requirements are managed in a product backlog of user stories. The user stories are ranked by priority and the highest priority items are detailed out.

Prior to planning/prioritizing the backlog, it is crucial to itemizing out the user stories with conditions of acceptance, and collaborating with the development team on an estimate for each story. As such, estimates can actually help the business to prioritize, so the estimation can happen early and often.

• Frequently run into software developers pertaining to the latest stories

Meeting often with the software developers to discourse about new stories and requirements that are being under consideration is also very important. Asking questions toward comprehending the constraints is another useful technique. Many a times, it is also significant to extract information as to how a story can be constrained to keep it minor or what meticulous requirements would entail supplementary toil. Some questions which are open-ended can act as follow-up on for estimating it the next time, comes handy in the event no useful information is available.

These kinds of discussions throw up some new perspectives amazingly – such as comprehending previously something minor which actually turn out to be a major story needing breaking it up which provide the much needed information to produce a backlog going to be helpful to developers during sprint planning.

• Highlight the product backlog in terms of priority and capacity

Prioritize the product backlog items that might be discussed in the subsequent limited sprints. Segregate the product backlog items up into releases or group them together in a general priority. The product backlog items can then be broken down as releases or segregated in a general priority. For the product backlog items for which capacity would be available in the upcoming sprints, the business can set the priorities for them.

• Factor out the top most precedence product backlog items

Marching forward toward sprint planning, it is imperative to ensure that detailed requirements accompany the product backlog items which are accorded top level priority. User stories capture these in-depth requirements. Apart from that, rough criteria of acceptance necessary to forego to provide the required approval for the story to be deemed “done or completed” should also be in place.

Priming the product backlog keeping in mind the near future should also be accorded significant priority as that would enable the preservation of the persistent impetus fueled by an Agile development methodology in an ever changing world.

To know more : http://www.scrumstudy.com/blog/importance-of-priming-the-product-backlog-for-value-added-sprint-planning/

Agile Sprint Planning

In a Scrum project, every sprint begins with Sprint Planning Meeting. The main objective should only be planning the sprint. Ensure that the meeting is attended by the all team members including the Product Owner, Scrum Master and the Scrum Team. You can also include part time resources for this meeting. This provides an important opportunity for the Scrum Team to select how much work they can do in the coming sprint.
Based on the Guide to Scrum Body of Knowledge (SBOK Guide), it is time-boxed to eight hours for a one-month Sprint and is divided into two parts – Objective Definition and Task Estimation.
1. Objective Definition—during the first half of the meeting, the Product Owner explains the highest priority User Stories or requirements in the Prioritized Product Backlog to the Scrum Team. The Scrum Team in collaboration with the Product Owner then defines the Sprint goal.
2. Task Estimation—during the second half of the meeting, the Scrum Team decides “how” to complete the selected Prioritized Product Backlog Items to fulfil the Sprint goal.
During Sprint Planning Meetings, the User Stories, which are approved, estimated, and committed are taken up for discussion. Each Scrum Team member does a quick estimation of tasks using tools such as planning poker. If the discussions start taking more time, it would mean that the User stories were not completely ready to be taken up for the sprint. Each Scrum Team member also uses Effort Estimated Task List to select the tasks they plan to work on in the Sprint, based on their skills and experience. The team reaches a consensus about the amount of work that need to put in this sprint. The Scrum Team also creates the Sprint Backlog and Sprint Burndown Chart using the User Stories and the Effort Estimated Task List during the Sprint Planning Meetings. The team can give a verbal commitment to complete the tasks planned for the sprint.
Try to avoid doing the following tasks during the meeting. They help you for preparation and should be prepared before the start of the meeting.
Grooming: Grooming helps ensure that refining of requirements and their User Stories is done well in advance of the Sprint Planning Meeting so that the team has a well-analyzed and clearly defined set of stories that can be easily broken down into tasks and subsequently estimated.
Updates/Revisions: Updates can include revisions to the original User Story estimates based on tasks creation and complexity factors discussed during the Sprint Planning Meeting.

Bottom line is that if you follow these points, you will be able to do effective planning without spending a lot of time.
To know more, please visit our blog: http://www.scrumstudy.com/blog/?p=811
Other Resources:
http://www.scrumstudy.com/why-get-scrum-certified.asp
http://www.scrumstudy.com/why-scrum.asp
http://www.scrumstudy.com/scrum-increases-ROI.asp