Importance of Sprint Planning Meeting in Scrum

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 have some more details on scrum,you can also visit:-

 http://xenelias-scrumblog.blogspot.in/2014/10/scrum-and-agile-brief-look.html

http://xeneliasscrum.wordpress.com/2014/10/31/benefit-realization-in-scrum

Product Owner

Product Owner

The key stakeholder of Scrum Projects is the Product Owner. One integral responsibility of the Product Owner is to convey the importance and significance of the Scrum Project to the Scrum Team. This is the key for the success of any Agile Project through the use of Product Backlog.

The Product Owner needs to be a person with a very solid understanding of the market trends, product, other competitors and future trends and strategies. However, this will vary depending on the type of the project that the team is developing i.e. hardware or software or commercial or for personal usage. Though it is the Product Owner who prioritizes the Product Backlog during the Sprint Meetings but it is the team that selects the work to be done in each sprint and total no of sprints needed.

The Product Owner does not have the authority to decide upon the number of sprints or allocating the sprints. That is the job of the Scrum Master to motivate the Scrum Team to perform their tasks and diligently and efficiently.

In exchange for the Scrum Master’s commitment the Product Owner will make a commitment to the Scrum Team to not throw new requirements at the team all of a sudden and give very aggressive deadlines.

The role of a Product Owner should be given to individual who has certain skills and traits including availability business savvy and good communication skills. The good Product Owners will show commitment to the Scrum Team to build the best possible product possible and also actively engage with other teams.

A Product Owner needs to know the nuances of the business very well because he or she has to make decisions based the market trends and market dynamics. He should be able to understand the market really well and also the business setup in order to make sound business decisions.

Last but not the least is communication, which is also largely a part of the Product Owners responsibilities. He/She is needed to work closely with the key stakeholders and communicate regularly to different people about the project at all times.

To have some more details on scrum,you can also visit:-

 http://xenelias-scrumblog.blogspot.in/2014/10/scrum-and-agile-brief-look.html

http://xeneliasscrum.wordpress.com/2014/10/31/benefit-realization-in-scrum/ 

Estimating Project Value in Scrum

Business justification is first assessed prior to a project being initiated and is continuously verified throughout the project lifecycle. This is a very important step in Scrum methodology. The project should make business sense in each and every part of its lifecycle. Estimation of the project value is a major way of establishing business justification. Estimating the project value helps the decision makers make the vital decision such as to continue with the existing project or not. The guide to Scrum body of knowledge (SBOK) provides insights into various methods which can be used to effectively measure the project value to aid the Scrum team in making very important strategic decisions. The value to be provided by business projects can be estimated using various methods such as Return on Investment (ROI), Net Present Value (NPV) and Internal Rate of Return (IRR).

These techniques captured from the guide to Scrum body of knowledge (SBOK) are explained below in detail:

Return on Investment (ROI): ROI when used for project justification assesses the expected net income to be gained from a project. It is calculated by deducting the expected costs of investment of a project from its expected revenue and then dividing this (net profit) by the expected costs in order to get a rate of return. Other factors such as inflation and interest rates on borrowed money may be factored into ROI calculations.

ROI formula:

ROI= (Project Revenue – Project Cost)/Project Cost

Frequent product or service increments, is a key foundation of Scrum that allows earlier verification of ROI. This aids in assessing the justification of continuous value.

Net Present Value (NPV): NPV is a method used to determine the current net value of a future financial benefit, given an assumed inflation or interest rate. In other words, NPV is the total expected income or revenue from a project, minus the total expected cost of the project, taking into account the time value of money.

Internal Rate of Return (IRR): IRR is a discount rate on an investment in which the present value of cash inflows is made equal to the present value of cash outflows for assessing a projects rate of return. When comparing projects, one with a higher IRR is typically better.

Though IRR is not used to justify projects as often as some other techniques, such as NPV, it is an important concept to know. 

To have some more details on scrum,you can also visit:- http://xenelias-scrumblog.blogspot.in/2014/10/scrum-and-agile-brief-look.html

http://xeneliasscrum.wordpress.com/2014/10/31/benefit-realization-in-scrum/ 

Benefit Realization in Scrum

Throughout a Scrum project,

 it is very important to ensure that intended benefits are being realized as originally planned. Strong benefit realization planning and appropriate verification techniques are required to confirm that the project deliverables with benefits and value are being created by the Scrum team members. This ensures full utilization of project resources. Prototype demonstration and functionality simulation are some of the techniques for confirming benefits and value.

A benefit realization plan helps to forecast contribution of individual project to the overall programme. The plan should be an integral part of any project from start to end. Benefit Realization plan helps to track the sustenance of intended benefits even after the end of a Scrum project.

First step towards benefit realization plan is to identify the intended benefits, stakeholders and the outcomes required followed by measurement of realized benefit, allocation of delivery responsibility, prioritization and identification of delivery dates. Prioritization helps to focus on the benefits with more impact.

Revisiting the Benefit Realization plan at predetermined review points helps the team members to decide whether the changes incorporated are still providing the intended benefits. If the answer is no, then the team should take corrective measures. Consensus of team members and their involvement towards the same output will help the team to move ahead in realizing the desired benefit.

A project manager is responsible for helping the customer gain the desired business benefits. However, the truth is that many successful projects have failed to deliver the desired benefits as planned. Working closely with customers can more clearly determine whether the features are adequate and it helps to make sure that the product gets embedded in the organization. Customers might realize the need for additional features; therefore, the development team should be able to accommodate such changes during product development. Meeting customer expectations and interpreting their requirements are key criteria in realizing benefits. It helps to gain more support from customers and stakeholders.

Some of the techniques and methodologies to confirm benefit realizations are carrying out visual presentation, demonstration of prototypes, workshops and training, arranging product release or launches, accommodating change and being creative in finding problem solutions. Change during such approaches must be sustained even after the end and it leads to realize desired benefits. After delivery of every successful project it is very important to ensure that the product or service that was delivered is used or implemented in the organization.

 To have some more details on scrum,you can also visit:- http://xenelias-scrumblog.blogspot.in/2014/10/scrum-and-agile-brief-look.html

http://xeneliasscrum.wordpress.com/2014/10/31/benefit-realization-in-scrum/ 

AGILE PROJECT FEASIBILITY

Introducing the known requirements to the feasibility team:

If you’re working on an agile project, one with volatile requirements or a tight deadline, you won’t have deep requirements when you begin the Feasibility phase. A request or idea has been approved for a feasibility investigation, and no one has documented detailed requirements to this point. Your idea is relatively new, and you’re working rapidly to either start the project or dismiss it. The information that is available is presented to the feasibility team. The idea usually has a champion or author who can meet with the team and go over the concept. This person brings in all the information they have at this point, whether it’s a diagram on a cocktail napkin, a detailed flowchart, or a mini functional specification. The following items can be analysed during the Feasibility phase:

·         User scenarios

·         Storyboards

·         User stories

·         Marketing proposals

·         Use cases

·         Competitive analysis

·         Rough sketches of process flow

·         Financial analysis

·         A website where a competitor is already using the idea

·         Mock-ups

If your idea comes from within, you may have a white paper created by someone to outline the idea.

What does a feasibility investigation look like?

When you present your idea to the feasibility team, they will provide initial feedback and subsequent commentary after performing their offline feasibility work. The initial review can provide positive feedback or identify issues immediately. You should inform the feasibility team that candid conversation is not only desired but critical to the process—you don’t want to go forward with more extensive feasibility analysis if you don’t think the idea is viable. You should also prepare the idea owner for candid feedback. Encourage the owner

to demonstrate their passion for the idea, but at the same time prepare them for frank conversation and a thorough review of the proposal. The time you spend on feasibility analysis will depend on various factors such as the idea’s complexity, the availability of the feasibility team, and dependency on third parties to provide information. An average feasibility analysis begins with a 1- or 2- hour meeting that kicks off the process; at this meeting, one person discusses the known requirements with the feasibility team. The feasibility team reviews the idea with the presenter, and team members ask questions about the customer, the project’s value, and potential technology needs. 

AGILE PROJECT FEASIBILITY

This first meeting may provide enough information to make the go/no go decision,

but usually a few questions remain that require team members to work offline to get the answers. This offline work may include the following:

·         Looking at existing code to see how it can support the request

·         Consulting with a vendor about a possible solution for the request

·         Doing deeper statistical analysis

·         Reviewing competitor functionality to see if they’ve addressed the same idea

Typically, the team regroups after 2 or 3 days to review their offline work. At this point, they usually have enough information to make the call about whether to continue to the Planning phase.

You can also visit my other blogs-

http://xenelias-scrumblog.blogspot.in

http://xeneliasscrum.wordpress.com