Tumgik
agileprinciples · 7 years
Text
Scalability of Scrum
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 collocated 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.
0 notes
agileprinciples · 7 years
Text
Risk Management in Scrum
Risk is defined as an uncertain event that can affect the objectives of a project and may contribute to its success or failure. Risks with a potential for positive impact on the project are called opportunities, whereas threats are risks that could negatively impact a project. Managing risk must be done proactively, and it is an iterative process that should begin at project inception and continue throughout the life of the project. The process of managing risk should follow some standardized steps to ensure that risks are identified, evaluated, and a proper course of action is determined and acted upon accordingly.
Risk Management consists of five steps:
Risk identification: Using various techniques to identify all potential risks.
Risk assessment: Evaluating and estimating the identified risks.
Risk prioritization: Prioritizing risk to be included in the Prioritized Product Backlog.
Risk mitigation: Developing an appropriate strategy to deal with the risk.
Risk communication: Communicating the findings from the first four steps to the appropriate stakeholders and determining their perception regarding the uncertain events.
Risk identification involves the Scrum Team members who attempt to identify all risks that could potentially impact the project. Only by looking at the project from different perspectives, using a variety of techniques, can they do this job thoroughly.
Risk assessment helps in understanding the potential impact of a risk, how likely it is to occur, and when the risk could materialize. The overall effect on business value should be estimated; if that impact is significant enough to outweigh the business justification, a decision must be made whether to continue the project. The assessment of risks is done with regard to probability, proximity, and impact. Probability of risks refers to the likelihood of the risks occurring, whereas proximity refers to when the risk might occur. Impact refers to the probable effect of the risks on the project or the organization. To estimate the probability of a risks, various techniques may be used, including Probability Trees, Pareto Analysis, and a Probability and Impact Matrix.  In addition to probability, risk assessment also evaluates the potential net effect of risks on the project or organization. These effects can be estimated using techniques such as Risk Models and Expected Monetary Value.
Under the risk prioritization step, Identified Risks are captured in a Prioritized Product Backlog—so a Prioritized Product Backlog could also be referred to as a Risk Adjusted Prioritized Product Backlog. The prioritized User Stories from the existing Prioritized Product Backlog and the prioritized list of risks are then combined to create an updated Prioritized Product Backlog which includes the Identified Risks.
Risk mitigation can beproactive or reactive. In the case of a risk, a plan B may be formulated, which can be used as a fall-back in case the risk materializes—such a plan B is a reactive response. Sometimes risks are accepted and are an example of a risk response which is neither proactive nor reactive. Risks are accepted because of various reasons, as in a situation where the probability or impact of the risk is too low for a response. Acceptance can also be the case in a situation where the apprehension of secondary risks may deter the product owner from taking any action. The effort made by the Product Owner to reduce the probability or impact—or both—of the risk is an example of a proactive response to mitigating risks.
Risk communication is important because stakeholders have an interest in the project and need to know the hindrances that the project may face. Information provided to stakeholders related to risk should include potential impact and the plans for responding to each risk. This communication is on-going and should occur in parallel with the four sequential steps discussed thus far—risk identification, assessment, prioritization and mitigation. The Scrum Team may also discuss specific risks related to their Tasks with the Scrum Master during Daily Standup Meetings. The Product Owner is responsible for the prioritization of risks and for communicating the prioritized list to the Scrum Team.
0 notes
agileprinciples · 7 years
Text
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.
0 notes
agileprinciples · 7 years
Text
Learn How to Conduct an Effective Backlog Grooming Session
A typical Prioritized Product Backlog will contain all User Stories, their time estimates (including any revised estimates), and the status of higher priority requirements. Any new or revised User Stories resulting from changes to business requirements, customer requests, external market conditions, and/or lessons learned from previous Sprints are also incorporated.
Product Backlog Review Meeting
Also referred to as a Prioritized Product Backlog Grooming Session, the Product Backlog Review Meeting is basically a formal meeting during the Groom Prioritized Product Backlog process, which helps the Scrum Team review and gain consensus about the Prioritized Product Backlog. However, other than the Prioritized Product Backlog Review Meeting, Prioritized Product Backlog grooming should happen throughout the project and can include situations in which the Product Owner writes new User Stories or reprioritizes User Stories in the existing Prioritized Product Backlog, Scrum Team members or Stakeholders give their suggestions about new User Stories to the Product Owner, and so forth.
Backlog Grooming Session
The Product Owner takes the lead in a Product Backlog Review Meeting which is conducted during the Groom Prioritized Product Backlog process. It is important that the Product Owner sets the objectives and ideally develop an agenda before the Product Backlog Review Meeting begins. Without these, the session will be unstructured and may prove unproductive. It is also important to limit the number of stakeholders participating in the meeting. Having too many participants tends to decrease the overall efficiency of the meeting. The Product Owner should invite only those stakeholders whose feedback is required for the grooming session. All Scrum Team members should be included because their input is valuable to the work being done and any issues encountered. If the grooming session results in any reprioritization of or change in the Prioritized Product Backlog, it is important that the team is in agreement with those changes.
Backlog Grooming Techniques
Develop Epic(s)
Create Prioritized Product Backlog
Conduct Release Planning
Create User Stories
Approve, Estimate, and Commit User Stories
Create Tasks
Estimate Tasks
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-analysed and clearly defined set of stories that can be easily broken down into tasks and subsequently estimated. Based on lessons learned from the current Sprint, there may be changes to requirements, or there may be reprioritization that can be easily incorporated into subsequent Sprints. Grooming supports and enhances the flexibility of the Scrum model by incorporating the latest business and technical insights into future Sprints.
0 notes
agileprinciples · 7 years
Text
Quality Comes in Large Quantities in Scrum
Competing video game companies—one that operates inside of the Scrum framework and one that does not—release similar games around the same time. The graphics and story-lines in each are fantastic. As gamer’s button mash their way through the campaigns, however, disparities emerge. Unlike its competitor, the company that operates inside of the Scrum framework finds little need to release patches for various game-play glitches. This is because those issues were neutralized during the company’s iterative quality testing throughout the production process—also known as Sprints—rather than saving that critical part of the process for the last minute.
In Scrum, quality is defined as the ability of the completed product or deliverable to meet the Acceptance Criteria and achieve the business value expected by the customer, according to A Guide to the Scrum Body of Knowledge (SBOK™ Guide). From small projects with six team members to large, complex projects with hundreds of team members, Scrum can be applied effectively to ensure quality is a staple in the production process.
To achieve this, Scrum adopts an approach of continuous improvement whereby the team learns from experience and stakeholder engagement to constantly keep the Prioritized Product Backlog updated with any changes in requirements. Any changes to the requirements reflect changes in the internal and external business environment and allow the team to continually work and adapt to achieve those requirements.
Since Scrum requires work to be completed in increments during Sprints, this means that errors or defects get noticed earlier through iterative quality testing, rather than when the final product or service is near completion. Moreover, important quality-related tasks—development, testing, documentation—are completed as part of the same Sprint by the same team. This ensures that quality is inherent in any deliverable created as part of a Sprint.
Continuous improvement with repetitive testing optimizes the probability of achieving the expected quality levels in a Scrum project. Constant discussions between the Scrum Core Team and stakeholders (including customers and users) along with actual increments of the product being delivered at the end of every Sprint reduces the gap between customer expectations and actual deliverable.
Between competitors, oftentimes it’s “game on.” But when a company commits to quality while operating within the Scrum framework, it’s game over.
0 notes
agileprinciples · 7 years
Text
Sprint Retrospective Meeting
Sprint Retrospective is a meeting convened by the Scrum Master in which the team talks about the previous sprint and decided on how to make the next sprint productive. This meeting differs from a Sprint Review meeting. In Sprint review meeting the team looks into what the team is currently working on whereas the Retrospective meeting talks about how they are working.
The team discusses on processes , communication, environment, artefacts and tools, practices.
Scrum is a framework that needs to be adjusted appropriately for a project, team and circumstance. The Sprint Retrospective meeting is a valuable instrument that allows a team to constantly develop and progress throughout the project.
In Scrum it is very key for all team members including the Product owner and Scrum Master to get an opportunity to voice their opinion in an truthful atmosphere. In some cases it may be beneficial to get an external enabler to attain the maximum advantage from retrospective. Also in cases where emotional conflicts are present in the team an impartial facilitator could be of help.
The duration of this meeting is usually time boxed to 3 hours and The participants of the meeting would be team members, product owner and scrum Master. However the attendance of the product owner is uncomplelled.
The meeting concentrates and getting answers on the below questions:
What are the positives during the sprint?
How to improve the next Sprint?
Irrespective of who joins the meeting , the atmosphere for Sprint Retrospectives must be harmless for participants. This infers that participants are required to be truthful and must be honest and apparent while considering others with respect. Issues performance and improvement can flare up in retrospectives. This can be handles by having a professional facilitator in the meeting.
Sprint Retrospectives are basically a method used to divulge the practices and activities of the Team to itself. It is considered that when a self organising team is self aware , it provides opportunities to correct one-self and improve. When a self-organizing system becomes self-aware, it self-corrects and deliberately improves when given the tools to do so.
However an ineffectively run Sprint Retrospective can do more harm than good to the team. It unnecessarily consumes the time of the team and can also be destructive to the team. Hence as stated earlier a professional facilitator is recommended to conduct the meeting at least when the team is newly following Scrum.
When Sprint Retrospectives work well, the team becomes more focused and  productive. Excellent teams do not simply appear. They evolve over time  and Sprint Retrospectives are a key ingredient in  for this.
0 notes
agileprinciples · 7 years
Text
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.
#scrum #agile
0 notes
agileprinciples · 7 years
Text
Learn How to Conduct an Effective Backlog Grooming Session
A typical Prioritized Product Backlog will contain all User Stories, their time estimates (including any revised estimates), and the status of higher priority requirements. Any new or revised User Stories resulting from changes to business requirements, customer requests, external market conditions, and/or lessons learned from previous Sprints are also incorporated.
Product Backlog Review Meeting
Also referred to as a Prioritized Product Backlog Grooming Session, the Product Backlog Review Meeting is basically a formal meeting during the Groom Prioritized Product Backlog process, which helps the Scrum Team review and gain consensus about the Prioritized Product Backlog. However, other than the Prioritized Product Backlog Review Meeting, Prioritized Product Backlog grooming should happen throughout the project and can include situations in which the Product Owner writes new User Stories or reprioritizes User Stories in the existing Prioritized Product Backlog, Scrum Team members or Stakeholders give their suggestions about new User Stories to the Product Owner, and so forth.
Backlog Grooming Session
The Product Owner takes the lead in a Product Backlog Review Meeting which is conducted during the Groom Prioritized Product Backlog process. It is important that the Product Owner sets the objectives and ideally develop an agenda before the Product Backlog Review Meeting begins. Without these, the session will be unstructured and may prove unproductive. It is also important to limit the number of stakeholders participating in the meeting. Having too many participants tends to decrease the overall efficiency of the meeting. The Product Owner should invite only those stakeholders whose feedback is required for the grooming session. All Scrum Team members should be included because their input is valuable to the work being done and any issues encountered. If the grooming session results in any reprioritization of or change in the Prioritized Product Backlog, it is important that the team is in agreement with those changes.
Backlog Grooming Techniques
Develop Epic(s)
Create Prioritized Product Backlog
Conduct Release Planning
Create User Stories
Approve, Estimate, and Commit User Stories
Create Tasks
Estimate Tasks
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-analysed and clearly defined set of stories that can be easily broken down into tasks and subsequently estimated. Based on lessons learned from the current Sprint, there may be changes to requirements, or there may be reprioritization that can be easily incorporated into subsequent Sprints. Grooming supports and enhances the flexibility of the Scrum model by incorporating the latest business and technical insights into future Sprints.
0 notes
agileprinciples · 7 years
Text
How do Scrum Teams Estimate Tasks in a Project?
Task planning and estimation is vital to develop products iteratively in accordance with the requirements specified in the Prioritized Product Backlog. The Scrum Team, in Task Estimation Meetings, estimates the effort required to accomplish each task in the Task List. The result of this process is an Effort Estimated Task List. The Scrum Team uses the Task list, a comprehensive list containing all the tasks to which the team has committed for the current Sprint, to develop an Effort Estimated Task List. The Task List must include any testing and integration efforts so the product increment from the Sprint can be successfully integrated into the deliverables from previous Sprints. Even though tasks are often activity based, the level of granularity to which the tasks are decomposed is decided by the Scrum Team.
During Task Estimation Meetings, the Scrum Team uses the Task List to estimate the effort required to complete a task or set of tasks and to estimate the people effort and other resources required to carry out the tasks within a given Sprint. One of the key benefits of this technique is that it enables the team to have a shared perspective of the User Stories and requirements so that they can reliably estimate the effort required. The information developed in the Task Estimation Meetings is included in the Effort Estimated Task List, and it is used to determine the velocity for the Sprint. In this workshop, the Scrum Team may use various techniques such as decomposition, expert judgment, analogous estimation, and parametric estimation. Task Estimation Meetings may also be combined with Task Planning Meetings.
To maintain relative estimation sizes and minimize the need for re-estimation the team uses estimation criteria. Estimation criteria can be expressed in numerous ways, with two common examples being story points and ideal time. For example, an ideal time normally describes the number of hours a Scrum Team member works exclusively on developing the project’s deliverables, without including any time spent on other activities or work that is outside the project. Estimation criteria make it easier for the Scrum Team to estimate effort and enable them to evaluate and address inefficiencies when necessary.
The output of task estimation is the Effort Estimated Task List. It is a list of tasks associated with the User Stories committed to in a Sprint. Typically, the accuracy of estimates varies with team skills. Estimated effort is expressed in terms of the estimation criteria agreed on by the team. This Effort Estimated Task List is used by the Scrum Team during Sprint Planning Meetings to create the Sprint Backlog and Sprint Burndown Chart.
0 notes
agileprinciples · 7 years
Text
What is a Persona?
Personas are highly detailed fictional characters, representative of the majority of users and of other stakeholders who may not directly use the end product. Personas are created to identify the needs of the target user base. Creating specific Personas can help the team better understand users and their requirements and goals. Based on a Persona, the Product Owner can more effectively prioritize features to create the Prioritized Product Backlog.
Creating a Persona
Creating a Persona involves assigning a fictional name and preferably a picture, like a stock image, to the character. The Persona will include highly specific attributes such as age, gender, education, environment, interests, and goals. A small group of users are selected to form the focus group and this group may be selected randomly from a large pool of users or can be selected specifically to represent all the major Personas being targeted. A quote illustrating the Persona’s requirements can be included as well. Below is an example of a Persona for a travel website.
An example for this concept Personas
Vanessa is a 39 year old resident of San Francisco. She is pursuing her passion for traveling after having a highly successful career as an attorney. She likes to have options while picking air travel and accommodation services so that she can choose the best and the most affordable. She gets frustrated with slow and cluttered websites.
0 notes
agileprinciples · 7 years
Text
Learn How to Conduct an Effective Backlog Grooming Session
A typical Prioritized Product Backlog will contain all User Stories, their time estimates (including any revised estimates), and the status of higher priority requirements. Any new or revised User Stories resulting from changes to business requirements, customer requests, external market conditions, and/or lessons learned from previous Sprints are also incorporated.
Product Backlog Review Meeting
Also referred to as a Prioritized Product Backlog Grooming Session, the Product Backlog Review Meeting is basically a formal meeting during the Groom Prioritized Product Backlog process, which helps the Scrum Team review and gain consensus about the Prioritized Product Backlog. However, other than the Prioritized Product Backlog Review Meeting, Prioritized Product Backlog grooming should happen throughout the project and can include situations in which the Product Owner writes new User Stories or reprioritizes User Stories in the existing Prioritized Product Backlog, Scrum Team members or Stakeholders give their suggestions about new User Stories to the Product Owner, and so forth.
Backlog Grooming Session
The Product Owner takes the lead in a Product Backlog Review Meeting which is conducted during the Groom Prioritized Product Backlog process. It is important that the Product Owner sets the objectives and ideally develop an agenda before the Product Backlog Review Meeting begins. Without these, the session will be unstructured and may prove unproductive. It is also important to limit the number of stakeholders participating in the meeting. Having too many participants tends to decrease the overall efficiency of the meeting. The Product Owner should invite only those stakeholders whose feedback is required for the grooming session. All Scrum Team members should be included because their input is valuable to the work being done and any issues encountered. If the grooming session results in any reprioritization of or change in the Prioritized Product Backlog, it is important that the team is in agreement with those changes.
Backlog Grooming Techniques
Develop Epic(s)
Create Prioritized Product Backlog
Conduct Release Planning
Create User Stories
Approve, Estimate, and Commit User Stories
Create Tasks
Estimate Tasks
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-analysed and clearly defined set of stories that can be easily broken down into tasks and subsequently estimated. Based on lessons learned from the current Sprint, there may be changes to requirements, or there may be reprioritization that can be easily incorporated into subsequent Sprints. Grooming supports and enhances the flexibility of the Scrum model by incorporating the latest business and technical insights into future Sprints.
0 notes
agileprinciples · 7 years
Text
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.
0 notes
agileprinciples · 7 years
Text
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. Scrum is easy to implement yet a very effective and powerful framework; a lot because of its philosophies, which are based on the following five governing principles:
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.
0 notes
agileprinciples · 7 years
Text
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.
0 notes
agileprinciples · 7 years
Text
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.
0 notes
agileprinciples · 7 years
Text
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.
0 notes
agileprinciples · 7 years
Text
Collaboration in Scrum
Collaboration in Scrum refers to the Scrum Core Team working together and interfacing with the stakeholders to create and validate the deliverables of the project to meet the goals outlined in the Project Vision. It is important to note the difference between cooperation and collaboration here. Cooperation occurs when the work product consists of the sum of the work efforts of various people on a team. Collaboration occurs when a team works together to play off each other’s inputs to produce something greater.
The core dimensions of collaborative work are as follows:
Awareness—Individuals working together need to be aware of each other’s work.
Articulation—Collaborating individuals must partition work into units, divide the units among team members, and then after the work is done, reintegrate it.
Appropriation—Adapting technology to one’s own situation; the technology may be used in a manner completely different than expected by the designers.
Collaboration ensures that the following project benefits are realized:
The need for changes due to poorly clarified requirements is minimized.
Risks are identified and dealt with efficiently. For example, risks to the project are identified and assessed in the Develop Epic(s), Create Deliverables, and Conduct Daily Standupprocesses by the Scrum Core Team members. The Scrum meeting tools such as the Daily Standup Meeting, Sprint Planning Meeting, Prioritized Product Backlog Review Meeting, and so on provide opportunities to the team to not only identify and assess risks, but also to implement risk responses to high-priority risks.
True potential of the team is realized. For example, the Conduct Daily Standup process provides scope for the Scrum Team to collaborate and understand the strengths and weaknesses of its members. If a team member has missed a task deadline, the Scrum Team members align themselves collaboratively to complete the task and meet the targets agreed to for completing the Sprint.
Continuous improvement is ensured through lessons learned. For example, the Scrum Team uses the Retrospect Sprint process to identify what went well and what did not go well in the previous Sprint. This provides an opportunity to the Scrum Master to work with the team to rework and improve the team for the next scheduled Sprint. This will also ensure that collaboration is even more effective in the next Sprint.
0 notes