Thursday, 6 July 2017

Value-based Prioritization in SCRUM

The Scrum framework is driven by the goal of delivering maximum business value in a minimum time span. One of the most effective tools for delivering the greatest value in the shortest amount of time is prioritization.
Prioritizing can be defined as determining the order and separating what must be done now, from what needs to be done later. The concept of prioritization is not new to project management. The traditional Waterfall model of project management proposes using multiple task prioritization tools. From the Project Manager’s point of view, prioritization is integral because certain tasks must be accomplished first to expedite the development process and achieve the project goals. Some of the traditional techniques of task prioritization include setting deadlines for delegated tasks and using prioritization matrices.

Scrum, however, uses Value-based Prioritization as one of the core principles that drives the structure and functionality of the entire Scrum framework—it helps projects benefit through adaptability and iterative development of the product or service. More significantly, Scrum aims at delivering a valuable product or service to the customer on an early and continuous basis.

Prioritization is done by the Product Owner when he or she prioritizes User Stories in the Prioritized Product Backlog. The Prioritized Product Backlog contains a list of all the requirements needed to bring the project to fruition.

Once the Product Owner has received the business requirements from the customer and written these down in the form of workable User Stories, he or she works with the customer and sponsor to understand which business requirements provide maximum business value. The Product Owner must understand what the customer wants and values in order to arrange the Prioritized Product Backlog Items (User Stories) by relative importance. Sometimes, a customer may mandate all User Stories to be of high priority. While this might be true, even a list of high-priority User Stories needs to be prioritized within the list itself. Prioritizing a backlog involves determining the criticality of each User Story. High-value requirements are identified and moved to the top of the Prioritized Product Backlog. The processes in which the principle of Value-based Prioritization is put into practice are Create Prioritized Product Backlog and Groom Prioritized Product Backlog.

Simultaneously, the Product Owner must work with the Scrum Team to understand the project risks and uncertainty as they may have negative consequences associated with them. This should be taken into account while prioritizing User Stories on a value-based approach (refer to the Risk chapter for more information). The Scrum Team also alerts the Product Owner of any dependencies that arise out of implementation. These dependencies must be taken into account during prioritization. Prioritization may be based on a subjective estimate of the projected business value or profitability, or it can be based on results and analysis of the market using tools including, but not limited to, customer interviews, surveys, and financial models and analytical techniques.
The Product Owner has to translate the inputs and needs of the project stakeholders to create the Prioritized Product Backlog. Hence, Value, Risk or uncertainty and Dependencies are the three factors considered while prioritizing the User Stories in the Prioritized Product Backlog.

Thus prioritization results in deliverables that satisfies the requirements of the customer with the objective of delivering the maximum business value in the least amount of time.

To Know More,Please Visit www.scrumstudy.com

Wednesday, 5 July 2017

Selecting appropriate Scrum Master(s) and identifying relevant Stakeholder(s)

Selecting appropriate Scrum Master(s) and identifying relevant Stakeholder(s) is crucial to the success of any project. In some projects, there may have been pre-conditions stipulating certain team members and their roles.
When there is flexibility in choosing the Scrum Master(s), the following are important Selection Criteria:
  • Problem-solving skills—This is one of the primary criteria to be considered while selecting Scrum Master(s). The Scrum Master(s) should have the necessary skills and experience to help remove any impediments for the Scrum Team.
  • Availability—The Scrum Master should be available to schedule, oversee, and facilitate various meetings, including the Release Planning Meeting, Daily Standup Meeting, and other Sprint-related meetings.
  • Commitment—The Scrum Master should be highly committed to ensure that the Scrum Team is provided with a conducive work environment to ensure successful delivery of Scrum projects.
  • Servant Leadership Style—Servant leaders employ listening, empathy, commitment, and insight while sharing power and authority with team members. Servant leaders are stewards who achieve results by focusing on the needs of the team. This style is the embodiment of the Scrum Master role
When identifying the Stakeholder(s), it is important to remember that stakeholders are all the customers, users, and sponsors, who frequently interface with the Product Owner, Scrum Master, and Scrum Team to provide inputs and facilitate creation of the project’s products. The stakeholders influence the project throughout its lifecycle.

To Know More,Please Visit www.scrumstudy.com

Risk Burndown Chart

In Scrum, the risk management activities are divided among various roles with some responsibility resting with everyone in the Scrum Team and the Scrum Master facilitating the process. Risk management is integral to ensuring value creation; therefore, risk management activities are performed throughout the project lifecycle and not just during project initiation.
Each risk could be assessed using different Risk Assessment tools. However, the preferred tool for assessing risks to create a Risk Burndown Chart is Expected Monetary Value (EMV).

The information gathered during risk assessment may be used to create a Risk Burndown Chart. This depicts cumulative project risk severity over time. The likelihoods of the various Risks are plotted on top of each other to show cumulative risk on the y-axis. The initial identification and evaluation of risks on the project and the creation of the Risk Burndown Chart are done initially. Then, at predetermined time intervals, new risks may be identified and assessed and remaining risks should be re-evaluated and updated accordingly on the chart. An appropriate time to do this is during the Sprint Planning Meeting. Tracking risks in this manner allows the team to recognize trends in risk exposure and take appropriate action, as necessary.

To Know More,Please Visit www.scrumstudy.com

Tuesday, 4 July 2017

Why story points are better than hours for estimation?

Adaptive planning is a key practice in Scrum methodology. This implies that extensive estimating in terms of hours, which is time consuming at the beginning of a project, is not an ideal practice on Scrum projects. It is a daunting task to estimate at the beginning of a project. To determine the number of hours required even before any work is done, can not only be difficult but also be riddled with inaccuracies. It is also difficult to foresee impediments during the course of the project. Factoring time required to overcome any possible obstacles might make the estimates seem inflated. Story points reduce the effort spent on estimation so that we can get the project off the ground as quickly as possible.

Using hours for estimation can make it difficult for us to relate to the progress of the project, especially since they are the same units used to measure our work weeks. For example, if a team completes 300 hours of work in one week and 200 hours of work in the next, we might perceive that the team is slacking although that might be due to the complexity of the tasks or due to other non-project related activities such as meetings.

Story point estimates are a relative way of estimating effort for tasks. They indicate the difficulty of a particular task. Story points for a task are calculated using known tasks as frame of reference. Story points estimate the size of the story and do not necessarily have to be linked with the number of hours that might be required to complete it. This ensures that the estimation is not subjective and is a metric for the entire team rather than being based on any one individual’s proficiency.

Fibonacci numbers (1,2,3,5,8,13,21,34,45 and so on) are commonly used to estimate story points. Alternately, any other sequence could be used to estimate them.

For example, if a task such as creating an input screen, for which we already know the amount of effort already required to complete, has been assigned 3 points, we use it as a frame of reference to estimate other tasks based on their perceived complexity.

To Know More,Please Visit www.scrumstudy.com

Scrum, the most popular agile method

Over the last few years, there has been a paradigm shift on how organizations manage projects. The global market faces increased pressures due to a demand for faster product development from customers, frequent changes in product requirements, and an expectation for development teams to be highly flexible and have cross-functional knowledge. Increased competition, rapid changes in the technological landscape and continued turbulence in business and economic fronts pushed the organizations to look beyond the traditional project management.
Many organizations found their answer in adaptive project management methods. Adaptive management is an iterative decision making process especially useful in rapidly changing and uncertain conditions. Adaptive project management uses a feedback process to reduce uncertainty in the future thereby embracing risk and uncertainty as tools to further understand the environment.

Agile is a group of product and service development techniques using an iterative and incremental approach in which solutions are delivered in stages. Agile promotes adaptive planning to develop a product in iterations, thereby, lending a greater flexibility to change during the development process while also reducing the extent of long-term planning. This minimizes the risk involved with changes in the long-term vision of a project. There are several Agile methods/frameworks developed over time such as Crystal, Scrum, Dynamic System Development Method, Extreme Programming, Kanban, Lean Product Development etc. Among the various frameworks, Scrum is the most matured and widely used framework across industries. About half of all Agile projects use Scrum.

1. Empirical process control: There are two ways to control any process—defined process control and empirical process control. Empirical process control is based on transparency, inspection, and adaptation. Scrum uses empirical process control to inspect and adapt, because this approach is more apt for processes that generate unrepeatable and unpredictable outputs.

2. Self-organization: As opposed to the traditional command-and-control style of management, Scrum believes that today’s workers have much more to offer than just their technical expertise and deliver greater value when self-organized. Scrum teams are cross-functional to ensure greater interaction.

3. Collaboration: Scrum believes that product development is a shared value creation process that needs all stakeholders working and interacting together to deliver the greatest value.
4. Prioritization: Delivering the greatest value in the shortest amount of time requires prioritization and dividing what will be done from what needs to be done.

5. Time-boxing: Time is treated as a limiting constraint, and time-boxing is used for all work
To know more about Scrum and how to deliver projects using Scrum, ‘Scrum Body Of Knowledge (SBOKTM Guide)’ is a recommended reading.

To Know More, Please Visit www.scrumstudy.com

Monday, 3 July 2017

All About Prioritized Program Backlog

The Prioritized Program Backlog plays a very similar role at the program level as the Prioritized Product Backlog does on project level. It identifies the requirements for the program and their priorities.
The items in the Prioritized Portfolio Backlog provide inputs to the various Prioritized Program Backlogs and, through Prioritized Program Backlogs, to Prioritized Product Backlogs of individual projects. As described for Prioritized Program Backlogs only minimal, if any, refinement of User Stories is done at this level, because the refinement is done in the projects and their specific Prioritized Product Backlogs.

There are a few differences, though:

The creation of the respective deliverables and their acceptance is done in the projects of the program. The done or acceptance criteria for each Product Backlog Item / User story may be defined on the program level.  Projects have to adhere to them but can add their own criteria.

The length of a Sprint is project specific and, generally, varies from project to project in a program. In addition, the velocity of different teams is, normally, not the same. Therefore, it is not necessary to have very granular User Stories at the program level. The refinement of User Stories at the program level goes only far enough to ensure that the respective story is clearly understood and tangible acceptance criteria for the program can be defined.

To Know More, Please Visit www.scrumstudy.com

Importance of Scrum Certification or Scrum training

Although there are many certifications such as ITIL, PRINCE2, which are implemented in organizations for achievement of goals through a project, Scrum training or Scrum certification can be described as one of the many courses where employees are groomed to become self-motivated and become keen to accept greater responsibility.
There is a famous proverb, “If you are comfortable with yourself, you will definitely be comfortable with others.” It also means the importance of self-confidence which points to becoming a self-organized individual in one’s life. Scrum certification emphasizes on the importance of self-organization which ultimately results in the following:
  •  Team participation and a feeling of self-ownership in members
  •  Employees are self-motivated which can lead to improved performance in a team
  •  New environment that is preferable for growth
A self-organized team does not convey the message that any team member can act in his/her own way as per their wishes. It strongly means that as soon as the definition of Product Vision is created in the Create Project Vision process, the concerned team members, the Product Owner, Scrum Master and the members of the Scrum team become noted and identified individuals. It has to kept in mind that the core team of Scrum also works very closely with important stakeholders for making changes and better improvements as they all pass through the Develop Epics and Create User Stories process. Every team member’s expertise is put to the test while assessing the inputs that are needed to execute the planned work of the project. The judgment aspects of all the team members are applied to every technical and management of the project during the phase of Create Deliverables process.

A Product Owner’s task as per the content of Scrum certification is to prioritize as he/she represents the Voice of Customer. The tasks of the self-organized Scrum team are to involve in break-down of tasks and estimation during the Create tasks and Estimate Tasks processes. Every team member should be aware of the work they are doing or handling as they are responsible for the tasks getting completed. One of the greatest advantages of Scrum certification or Scrum training is that in the execution of Sprint, if any of the team members require help for finishing the assigned tasks, it is addressed through the regular interaction that is mandatory during the Daily Standup Meetings. The members of the Scrum Team regularly interact with other teams via the Scrum of Scrums (SoS) Meetings and they can look for additional guidance when needed from the Scrum Guidance Body.

Since meetings are held regularly with customers and stakeholders, every sprint will bear the required changes and improvements needed and at last, the Scrum Teams would have designed the product or service as accepted by the clients.

To Know More, Please Visit www.scrumstudy.com