The Process

When a customer (internal or external) comes to the team with a certain need, the final product is broken up into individual chunks.
(Traditionally this has been a software need, but the process also works for any project that is comprised of multiple stages and
pieces, such as a marketing launch.) The pieces are prioritized and tackled in a series of short bursts called sprints. Teams can
determine their own sprint length, provided it’s less than 4 weeks (one to two weeks is common). At the end of each sprint, the
team delivers a product increment — essentially, a version of the product that could be shipped if necessary. Transparency is a key
principle in Scrum, so teams and stakeholders review the results of each sprint together. This ensures everyone's on the same page
about priorities and deliverables, and any adjustments can be made right away.

Teams promote internal transparency through daily standups. During these brief, 15-minute meetings, everyone reports what they
accomplished yesterday, what they plan to work on that day, and any current “impediments" (factors that are keeping them from
working more efficiently). This visibility helps uncover problems and bring them to the forefront quickly, so the team can tackle and
overcome them together.

Who’s Who: Scrum Roles

There are three main roles in Scrum: the product owner, the scrum master, and the development team.
Product Owner: Product owners represent the customer's interests. They decide what the team will work on next, so the team's
efforts stay focused on high-priority tasks that create the most value. The Kanban product owner must always be available to
provide input or guidance to the development team, although it's important to note that product owners are not managers — scrum
teams self-organize.
Scrum Master: The Scrum master's #1 goal is to help the development team be self-sufficient. Scrum masters intercept and remove
barriers to team progress, and act as a buffer between the team and any outside forces that might interfere with productivity. S/he
leads daily standup meetings, so while the product owner is responsible for what the team will produce, the scrum master oversees
the how.
Development Team: Development teams are made up of cross-functional team members, so the group has all the necessary skills to
deliver the final product. The team focuses on only one project at a time; members don’t multitask or split their efforts between
multiple projects. Once the product owner makes an ordered list of what needs to be done, the development team decides how
much they can complete in a single sprint and plan accordingly.

Core Values
As an Agile framework, Scrum shares the values of the Agile Manifesto. But it also creates its own guidelines. These are the five
golden rules in Scrum:
Openness: Scrum sees collaboration as the most effective way to create the best possible product. So teamwork and transparency
are essential. Rather than anxiously downplaying  problems, Scrum team members are open about their progress and any
roadblocks they encounter.

Focus: With Scrum, multitasking is out. Since productivity is key, splitting the team’s attention across multiple projects, or redirecting
their efforts mid-sprint by shifting priorities, is avoided at all costs. Instead, teams concentrate on the task at hand for the highest
velocity and best quality product.

Courage: Teams must have the tenacity to commit to an ambitious (but attainable) amount of work for each sprint. Scrum masters
must also be able to stand up to stakeholders if necessary, and the product owner must guide the development team with authority.

Commitment: Each sprint is itself commitment: teams must agree on what they’re going to accomplish and stick to it. This value is
reflected in each team’s unique “Definition of Done,” a list of criteria to determine whether a feature or deliverable is truly finished
— that it’s not only fully functional, but meets the team’s standards for quality.

Respect: In the service of true collaboration, roles and responsibilities are transparent. Each member of the team is respected
equally, regardless of job description, seniority, or status. The development team must honor the product owner’s authority in
deciding what the team works on, and the product owner needs to respect the team’s need follow whatever work process is best for
them.
Now that you've got the basics, are you curious about the pros and cons of Scrum (and other top project management
methodologies, such as Kanban vs. Scrum)? Wondering what are the 5 Scrum ceremonies? Read our Quick-Start Guide to Project
Management Methodologies and you'll be an expert in no time!

----------------------------------------------------------***********************---------------------------------------------------------------------
https://www.wrike.com/blog/project-management-basics-a-review-of-pm-methodologies-part-1/
Project Management Methodologies Review (Part 1)

Choosing a project management methodology is like choosing which recipe to follow when baking chocolate chip cookies. One
recipe might use room-temperature butter while another recommends melted margarine, or call for dark chocolate instead of semi-
sweet chips. Each recipe gives you delicious cookies, but the steps, ingredients and techniques are all a little different to suit your
tastebuds. You should pick your PM methodology based on your available ingredients: project constraints, timeline, tools, and
people.
Read through this list of common project management methodologies and see if they sound like they fit your project or
organization. We include brief descriptions, pros, and cons for each, and if one captures your attention, we definitely encourage
further research.

Here's the first half of our PM methodologies list:

1. Adaptive Project Framework (APF)
The APF method strives to learn from experience. These projects begin with a Requirements Breakdown Structure to define strategic
project goals based on product requirements, functions, sub-functions, and features. As they proceed, teams continually evaluate
previous results to improve policies and practices at each stage of the project lifecycle. Clients/stakeholders can change
project scope at the start of each stage so the team can produce the most business value.
PRO: This is a good approach for when you know what your goal is and aren't sure of the best way to get there.
CON: Due to its flexibility, the Adaptive Framework may lead to project delays or increased budgets.

2. Agile Project Management
Great chefs taste their food as they cook so they can add new ingredients to create the best dish. Agile is like tasting our project as
we go and adjusting it accordingly. Planning begins with clients describing how the end product will be used, its benefits, and so on,
so the team gets a good understanding of the expectations. Once the project has begun, teams cycle through the process of
planning, executing, and evaluating tasks — which might change the final deliverable. Continuous collaboration is key, both among
team members and with project stakeholders, to make fully-informed decisions.
PRO: This approach is beneficial for creative projects with goals that are flexible and can be modified midway.
CON: Timelines and budgets are difficult to define, and stakeholders must have the time and desire to be actively involved in the
day-to-day work.
Confused about the difference between APF and Agile?  We’ll break it down for you: with APF, your end goal is clear, but your
method for achieving that goal will change based on your experience at each stage of the project. With Agile, your end goals are less
defined. Each stage brings feedback from stakeholders to help guide your decisions and improve or alter the final product.

3. Benefits Realization
This project management methodology redefines success as not just delivering the package on time and with money to spare, but
achieving a desired benefit. Here's an example: say your clients want to increase their sales conversion rate by 15%. They hire you to
manage the development of a new CRM software that will help the sales team personalize their communications, track sales data,
and determine ideal communication timelines. You deliver a CRM with those features on time and within budget. Success, right?
What if your client's sales conversion rates only increase by 5%? With benefits realization, your project isn't successfully completed
until the client's desired benefits are achieved — in this case, until the sales conversion rate is up 15%.
PRO: This approach ensures that your projects contribute real value to the business and deliver the end results your stakeholders
care about.
CON: Benefits aren't always exact, measurable, or scientific, so it can be difficult to know if they've been achieved — or if your
project actually contributed to that success. You'll need to put careful thought into developing effective metrics to measure the
outcomes of your project, such as ROI, process capability, faster delivery times, or higher customer satisfaction.
4. Critical Chain Project Management (CCPM)
Project delays are usually caused by resources that aren't available when you need them. CCPM avoids that by building a project
schedule that first identifies a "critical chain" of tasks and then reserving resources for those tasks. Your project timeline may be
longer, but you’ve got a higher probability of predicting realistic deadlines.
PRO: Tasks can be collaborated on because you know that all key players are available when you need them.
CON: This approach may not be effective for projects with short deadlines, since CCPM plans build in extra time buffers along the
critical chain.

5. Critical Path Method (CPM)

Determine your project's shortest timeline and adjust to shifting deadlines using CPM. You'll start by looking at all the tasks
absolutely necessary to complete your project, and then estimating completion times for each step, including task dependencies,
milestones, and final deliverables.
PRO: Specific dates can be assigned to each task, so managers can compare what should be happening with what is happening on a
daily basis. It's optimal for projects with short deadlines.
CON: Critics say a major drawback is that CPM doesn’t consider resource availability in planning, so you may be left with an overly
optimistic plan.

6. Event Chain Methodology (ECM)

Most projects don’t go exactly according to plan. Risks are difficult to identify and analyze, and project managers may be under
pressure by stakeholders to create optimistic timelines, budgets, or deliverables. Event chain methodology helps recognize and plan
for potential risks that may lie outside the project scope. By using techniques like Monte Carlo Analysis and Event Chain Diagrams,
project managers can see how external events affect project tasks and determine the probability of certain risks occurring.
PRO: By visualizing the relationship between external events and tasks, managers can create more realistic project plans.
CON: It's easy to forget that external events aren't just threats to your project — they can also present opportunities. Don't
automatically squash all potential risks and fail to capitalize on fortunate circumstances.

7. Extreme Programming (XP)

XP features short development cycles, frequent releases, and constant client collaboration. Productivity is high, and the approach is
well-suited to complex or undefined projects. These teams allow for change within their sprints; if the team hasn't started work on a
feature, a similar task can be swapped out to replace it. Teams avoid overworking themselves through effective collaboration and by
writing the simplest possible code to produce the desired feature.
PRO: XP is efficient, with a focus on simplicity. Teams work at a sustainable pace, meaning no 80-hour work weeks leading to
burnout and low-quality output.
CON: Critics warn that the XP approach's strength lies too much in the ingenuity of unique team members rather than with process
itself.

8. Kanban
If a continuous workflow and outputting a slow and steady stream of deliverables are your main priorities, Kanban is your man.
Managers create visual representations for the workflow (often using a whiteboard or sticky notes) to uncover process problems and
prevent tasks from stalling as "works in progress." The sticky notes move across the board to tangibly represent project progress.
PRO: Kanban helps teams understand where their time is really being spent so you can improve efficiency.
CON: Variations in customer demand — like the start of the holiday season, or a drop-off due to a recall — can make Kanban
inefficient, since it’s designed to produce a steady output.
Find a project management methodology you like? Itching for more bite-sized breakdowns? Stay tuned for Part 2 of this post, where
we'll cover 8 more essential methodologies as the next chapter in your PM handbook.
Project Management Methodologies: A Quickstart Guide (Part 2)

Now that you’ve mastered the lingo and have a firm grasp on our first 8 common Project Management methodologies, you’re
starting to settle into your new PM role. You’re gearing up for your first project kickoff, and the boss is back in your office: “So, let’s
talk methodologies. What do you think is the best strategy for our company?” Gulp.
Don’t panic — you’ve got this. We’ll give you the rundown on 8 more PM methodologies so you can choose the winning approach
every time.
Here are the next 8 project management methodologies:

1. Lean PM
"Waste not, want not!" Lean project management is all about finding the path of least resistance to get the results you want. You
identify and cut out waste (or mura), starting by examining your full work-process breakdown to find and eliminate bottlenecks and
delays. Teams focus on the project's true customer value, and on continuous process improvement. The goal is to do more with less:
deliver high value, high quality work with less manpower, less money, and less time.
PRO: This approach is especially helpful if you need to find ways to cut your budget, meet quick deadlines, or get big results with a
small team.
CON: Since the ultimate goal is to get things done faster and cheaper, stakeholders need to make prompt decisions and be prepared
to stick to those decisions -- weighing options for 2 weeks interrupts the Lean process.

2. PRINCE2
Not to be confused with the first Prince. Also known as "PRojects IN Controlled Environments." The project must have a business
justification, so the first step is identifying a clear need, targeted customer, realistic benefits, and thorough cost assessment. A
project board owns the project and is responsible for its success, while a project manager oversees day-to-day activities.
PRO: The extensive documentation involved in PRINCE2 projects can be very helpful with corporate planning and performance
tracking.
CON: It can be difficult to adapt to project changes, since a lot of effort goes into creating and maintaining those documents and logs
at each stage of the process.

3. PRiSM
Want to go green? PRiSM (PRojects integrating Sustainable Methods) blends project planning with environmental sustainability
measures.
PRO: Aligning corporate strategy with social responsibility can bolster a company's reputation, plus you could benefit from reduced
energy, waste management, and distribution costs.
CON: Environmental responsibility must be a priority at every level of the company -- from executives to managers -- for it to be
truly successful.

4. Process-Based Project Management
It's all about "mission accomplished." Every project is defined by your company mission or vision statement, whether that be "Feed
the Homeless" or
"Improve Global Collaboration." Before project kick-off, the plan is analyzed to see if it will live up to your mission statement; if it
won't then all strategies and goals are adjusted in order to meet that objective.
PRO: This approach helps ensure that every project aligns with, and adds value to, the organization's strategic vision.
CON: Adjusting every team's projects and processes to fit the mission can be very time-consuming. And it doesn't allow for side
projects, so if your company wants to take on tasks unrelated to your values you'll have to revisit your company mission statement
first.

5. Scrum
"Productivity" is the name of the game. Small teams are facilitated by a scrum master, whose job is to remove any barriers to team
progress. Work is typically done in a series of two-week sprints, and team members are in constant communication through daily
scrum meetings.
PRO: New developments can be tested quickly and mistakes are fixed right away.
CON: Scrum projects are prone to scope creep. Because the team is a close unit, one member leaving can also disrupt the whole
project.
 
**Confused about the difference between Scrum and XP (from Part 1)? XP teams tackle tasks in a strict customer-determined order,
whereas Scrum teams can determine their own timeline. Additionally, XP allows similar tasks to be swapped within a sprint, but Scrum
tasks are meant to be set in stone until the end of the sprint. 
 
6. Six Sigma
What's your sigma rating? Six Sigma is a quality-improvement process aimed at reducing the number of defects in manufacturing
and industrial sectors, or the bugs in software development. A rating of "six sigma" indicates that 99.99966% of what is produced is
defect-free.
PRO: Six Sigma is a very proactive methodology, and it examines the entire production process to identify process improvements
even before defects appear.
CON: This holistic approach may also lead to rigidity in the planning process, which could limit your team's creativity and innovation.

7. Lean Six Sigma

It combines Lean's efficiency with Six Sigma's statistics-based process improvement. It corrects workflow problems and eliminates
waste by helping you understand how work gets done and identify which aspects of your project are most valuable to the client or
customer.
PRO: In addition to making your projects more efficient and cost effective, Lean Six Sigma keeps employees actively engaged in
process improvement, leading to a sense of ownership and accountability.
CON: Lean Six Sigma usually involves major change to the way work gets done, so make sure you -- and company execs,
stakeholders, and other managers -- are prepared for the amount of time, effort, and resources needed to be successful with this
method.

8. Waterfall
Imagine the path of a waterfall: The river runs from the top and flows down to the bottom without steering away from the main
course. It's the same in project management. With clearly defined goals and a set timeline, teams work through tasks in sequence,
completing one before moving on to the next in line.
PRO: Extensive planning goes into this approach, and this thoroughness often results in more accurate timelines and budgets.
CON: It is difficult to adapt to any project changes — or modify and correct previous steps (water can't run backwards!) — so you'll
need to be proactive in anticipating problems before they can affect your flow.

16 methodologies later, and we're confident that you have the knowledge you need to confidently lead your team to success. Now
it's time to decide which is best suited for your company and projects, and get things done!
Which PM Methodology does your company use? Share your first-hand pros and cons in the comments below.
See this next: All 16 Project Management Methodologies in One Simple Infographic
ScrumMaster (https://www.mountaingoatsoftware.com/agile/scrum/roles/scrummaster)
What is a Scrum Master? The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum.
The ScrumMaster is often considered a coach for the team, helping the team do the best work it possibly can. The ScrumMaster can
also be thought of as a process owner for the team, creating a balance with the project's key stakeholder, who is referred to as the
product owner.
The ScrumMaster does anything possible to help the team perform at their highest level. This involves removing any impediments to
progress, facilitating meetings, and doing things like working with the product owner to make sure the product backlog is in good
shape and ready for the next sprint. The ScrumMaster role is commonly filled by a former project manager or a technical team
leader but can be anyone.
The ScrumMaster is also often viewed as a protector of the team. The most common example is that the ScrumMaster protects the
team by making sure they do not over-commit themselves to what they can achieve during a sprint due to pressure from an overly
aggressive product owner. However, a good ScrumMaster also protects the team from complacency.

What is a Scrum Master role and how does it fit into the project?  

Many who are new to the ScrumMaster role struggle with the apparent contradiction of the ScrumMaster as both a servant-leader
to the team and also someone with no authority.

The seeming contradiction disappears when we realize that although the ScrumMaster has no authority over Scrum team members,
the ScrumMaster does have authority over the process. Although a ScrumMaster may not be able to say, “You’re fired,” a
ScrumMaster can say, “I’ve decided we’re going to try two-week sprints for the next month.”

The ScrumMaster is there to help the team in its use of Scrum. Think of the help from a ScrumMaster as similar to a personal trainer
who helps you stick with an exercise regimen and perform all exercises with the correct form. A good trainer will provide motivation
while at the same time making sure you don’t cheat by skipping a hard exercise. The trainer’s authority, however, is limited.

The trainer cannot make you do an exercise you don’t want to do. Instead, the trainer reminds you of your goals and how you’ve
chosen to meet them. To the extent that the trainer does have authority, it has been granted by the client. ScrumMasters are much
the same: They have authority, but that authority is granted to them by the team.

A ScrumMaster can say to a team, “Look, we’re supposed to deliver potentially shippable software at the end of each sprint. We
didn’t do that this time. What can we do to make sure we do better the next sprint?” This is the ScrumMaster exerting authority
over the process; something has gone wrong with the process if the team has failed to deliver something potentially shippable.

But because the ScrumMaster’s authority does not extend beyond the process, the same ScrumMaster should not say, “Because we
failed to deliver something potentially shippable the last sprint, I want Tod to review all code before it gets checked in.” Having Tod
review the code might be a good idea, but the decision is not the ScrumMaster’s to make. Doing so goes beyond authority over the
process and enters into how the team works.

With authority limited to ensuring the team follows the process, the ScrumMaster’s role can be more difficult than that of a typical
project manager. Project managers often have the fallback position of “do it because I say so.” The times when a ScrumMaster can
say that are limited and restricted to ensuring that Scrum is being followed.

--------------------------------------------XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-----------------------------------------------------------------
Scrum Master
A Scrum Master is a facilitator for an Agile development team. They are responsible for managing the exchange of
information between team members. Scrum is a project management framework that enables a team to communicate
and self-organize to make changes quickly, in accordance with Agile principles.
Although the scrum analogy was first applied to manufacturing in a paper by Hirotaka Takeuchi and Ikujiro Nonaka, the
approach is often used in Agile software development and other types of project management. The term comes from
the sport rugby, where opposing teams huddle together during a scrum to restart the game. In product development,
team members huddle together each morning for a stand-up meeting where they review progress and essentially restart
the project.

What does a Scrum Master do?

A Scrum Master leads a scrum. Scrums are daily meetings conducted by Agile, self-organizing teams that allow the team
to convene, share progress and plan for the work ahead. Some teams have a fixed Scrum Master, while others alternate
the role with various team members occupying the position on different days. No one approach is right, and teams can
choose to appoint the Scrum Master role as best fits their needs.
During the daily meetings, the Scrum Master asks the team members three questions:
1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?
The Scrum Master then uses the answers to those questions to inform tactical changes to the team's process, if
necessary.

Roles, responsibilities and skills of a Scrum Master

Although the title of Scrum Master sounds powerful, this position is not the project leader and is not held accountable
for project outcomes; this responsibility is given to the team as a whole. The official Scrum Guide refers to the Scrum
Master as a servant leader because their purpose serves the team through the scrum process, creating a framework in
which every team member can do their best work to meet a common goal.
An ideal Agile team would have the team -- not one individual -- manage its process. However, the Scrum Master
position evolved to take responsibility while keeping the process as team-oriented as possible.
The Scrum Master is a highly dynamic role, and is responsible for:
1. Helping the team to reach consensus for what can be achieved during a specific period of time -- referred to as
a sprint.
2. Helping the team to reach consensus during the daily scrum.
3. Helping the team stay focused and follow the agreed-upon rules for daily scrums.
4. Removing obstacles that are impeding the team's progress.
5. Protecting the team from outside distractions.
6. Ensuring product backlog items are clearly defined and managed efficiently.
The Scrum Master's main role is that of a facilitator. They ensure that best practices are followed and that the team's
projects progress. A scrum that follows best practices should encourage transparency, inspection and adaptation.
Common skills required of a Scrum Master include:
 The ability to facilitate communication between team members and to promote a sense of community.
 The ability to help team members adapt to new situations through coaching and training.
 The ability to communicate the team's progress and needs to external teams.
 The soft skills and empathy to handle changing interpersonal dynamics, behavioral patterns and conflict
resolution.
In addition to the Scrum Master, other scrum roles include the project manager and product owner, which are different
but equally significant responsibilities on the team. These roles will work together with the Scrum Master to achieve a
well-defined common goal.

Who needs a Scrum Master?

Teams that follow an Agile methodology and aim for a team-centric process with a bottom-up management style benefit
from the Scrum Master role. In development, teams of this kind often exist at the beginning of the technology value
stream. This is because the nature of development work often requires a high degree of flexibility and collaboration.
Objectives may change from day to day, and timelines may contract or expand depending on external requirements. The
Scrum Master implements enough structure to keep the team's development effort focused while ensuring the team
remains adaptable, as changes to the plan are inevitable and even welcome.
Some teams may find that a Scrum Master is not necessary if every team member understands scrum methodology and
can manage their workflow in harmony with other team members. The ideal scrum has no "master" and gives each team
member an equal role in managing workflow. However, many teams find that having a designated Scrum Master is
helpful to streamline the process. Scrum Masters are also sometimes hired as consultants.

Benefits of employing a Scrum Master

Some benefits of employing a Scrum Master are:
 Scrums will have a designated leader specialized for the job.
 Teams will adopt agile methodologies and a culture of failure to increase their overall adaptability. A culture of
failure views failures as opportunities instead of setbacks.
 An increased ability of the entire organization to adopt Agile methodologies and to transition from traditional
waterfall methodologies.
 The Scrum Master's team will have a servant leader dedicated to meeting individual needs and promoting the
happiness of the team.
Some organizations choose to hire Scrum Masters as consultants instead of designating an in-house employee. The
added benefit of hiring an external Scrum Master is that they do not have preexisting biases about the organization and
can bring fresh ideas.

Scrum Master vs. product owner

Scrum Masters and product owners are alike in that they both are responsible for managing and optimizing the product
backlog. They both predict the necessary work to deliver a successful product.
However, they differ in their approach to this goal. The product owner approaches work with a top-down approach to
delivering a successful product by planning far ahead and developing a course of action for the team to follow. The focus
is on the bigger strategy.
The Scrum Master, by contrast, is less concerned with a long-term strategy and is more concerned with noticing
immediate issues and reacting to them as they crop up. The focus is on employing tactics to fine-tune the team's process
as time goes on.

Scrum Master vs. project manager

Scrum Masters and project managers have the same objective -- to help their teams get work done efficiently. The
difference is in their approach to this goal.
Project managers inhabit a more traditional management role. They focus on progress reports, milestones and strict
project timelines, for example. They are goal-oriented and focus on controlling the team from the top-down to achieve
the goal.
Scrum Masters, by contrast, are process-oriented. Instead of setting a collection of goals and restrictions for a team to
ensure it stays on track, the Scrum Master focuses on streamlining and optimizing the processes that help teams meet
their goals. They take a bottom-up approach to management and view themselves as team member instead of a team
manager.

Build an agile cybersecurity program with Scrum

The Scrum framework is a method that focuses on teamwork, accountability and iterative processes for product
development, with products being hardware, software or functions. Organizations throughout the world are steadily
adopting Scrum, especially in the world of agile software development projects.

So, what does this have to do with a cybersecurity program? By understanding and applying aspects of Scrum, security
admins can improve how they develop, implement and manage processes and controls, effectively building an agile
cybersecurity program. Here's how.

Scrum development framework basics

Core principles
Scrum is a flexible, lightweight process framework based on well-defined principles. There are four Scrum principles
particularly relevant to cybersecurity projects:
1. Transparency: Development, implementation and management processes must be visible and understandable
to all persons involved with the processes. Project team members must have a common understanding of
project goals and a standard terminology to describe project status -- especially agreement on when a project
task is done or ready to use.
2. Inspection: Project work and progress must be frequently reviewed so that the project team can quickly identify
issues that are impacting or could impact the project goal. Scrum includes several events designed to effectively
meet this principle. This principle leads to increased visibility and accountability for stakeholders and project
team members.
3. Adaptation: If a review determines that one or more aspects of a process are preventing or could prevent
project deliverables from being usable, the process must be adjusted as soon as possible. This leads to higher
quality work and ensures the project appropriately supports business goals and objectives.
4. Timeboxing: All Scrum events have defined minimum and maximum durations. This ensures efficient use of
project team members' time and helps the team deliver the highest business value in the shortest time.

Project team
The core of Scrum is a small project team, typically between three and nine members. The team is intended to be highly
flexible, productive and continuously improving. The team is also meant to be self-organizing; it should determine how
best to accomplish its work. The team should be cross-functional and should have all the skills needed to accomplish a
project without being overly dependent on nonteam persons.

How to implement Scrum for agile cybersecurity

Once organizations understand the theory of Scrum, they can better implement the Scrum development framework for
security purposes. Organizations can use practical Scrum techniques to improve the development, implementation and
management of cybersecurity projects.
The following example illustrates how Scrum techniques could be used to help develop and implement a security
operations center (SOC).
User stories
It is critical for security teams to support key business objectives. Cybersecurity pros need to clearly understand project
stakeholder requirements when developing or implementing agile cybersecurity controls or processes.
In Scrum, user stories describe desired high-level functionality, as shown in the following example:
 As a CISO (who?),
 I want the SOC to track how many phishing emails are clicked on by employees each month (what?)
 so that I can report the risk of phishing to the board of directors (why?).
Note that user stories are intended to communicate what a user wants -- not how to achieve the desired functionality. It
is up to the project team to determine the how. User stories help ensure high-quality work and regular alignment
between the project team and stakeholders.

Product backlog
The Scrum product backlog is a prioritized, descriptive list of all features, functions, requirements, enhancements and
fixes that are known to be needed in a product -- for example, SOC SIEM, SOC use cases, SOC key performance indicators
(KPIs), SOC escalation procedures, SOC employees or physical space for SOC. It is the authoritative source of
requirements for any changes to be made to a product -- in this case, implementing additional SOC use cases. Product
backlog items often are based on user stories and include tests that must be used to determine when an item is
completed.
A key stakeholder, called a product owner, is responsible for managing the backlog.

Sprints
A sprint is a two- to four-week miniproject during which one or more objectives of the overall project are accomplished.
In the case of the SOC hypothetical, objectives might include developing requirements for SOC SIEM selection or
developing SOC KPIs. The objectives originate from the product backlog.
The work to be performed in a sprint, also known as sprint goals, is planned before a sprint begins. Team members
should discuss and answer the following three questions when sprint goals are outlined:
1. What is the most valuable or important objective to accomplish next?
2. What can the team realistically accomplish in the upcoming sprint?
3. How will the work needed to reach the selected objective be achieved?
Sprints help teams break projects down into smaller, more manageable work items. They also enable faster feedback
and limit the risk of a project going awry in a short period of time.

Daily Scrum meeting

The project team gathers each day for a 15-minute meeting. Daily Scrum meetings should be held at the same time and
place each day. The main purpose of the meeting is for the team to quickly discuss progress toward the sprint goal and
to identify any issues that may slow down or block future progress.
Each meeting participant should briefly answer the following questions:
1. What did I do yesterday to help the team meet its sprint goal? For example, I created three SOC use cases.
2. What will I do today to help the team meets its sprint goal? For example, I will create two more SOC use cases.
3. Do I see any impediment that prevents me or the team from meeting the sprint goal? For example, I can't create
a specific use case because another employee won't provide me with required information.
Daily Scrum meetings enhance team communication and help quickly identify and resolve issues.

Sprint review
A sprint review should be held at the end of each sprint to inspect the work done during the sprint and to modify the
product backlog as needed. Project team and key stakeholders attend the meeting, which should last no more than two
hours.
The following key tasks should be performed at the meeting:
 The product owner explains what product backlog items have been done in the sprint.
 The project team demonstrates the work that it has done and answers questions about the work.
 The product owner discusses the current product backlog and projects' likely completion dates based on
progress to date.

Sprint retrospective
The goal of the retrospective is to review project team processes and dynamics after every sprint. During the meeting --
which typically lasts one to two hours -- all team members should openly and honestly discuss the following questions:
 What went well during the sprint?
 What didn't go well during the sprint?
 What can the team improve on for the next sprint?
Similar to the lessons learned meeting that should occur after a significant cybersecurity incident, the retrospective
helps ensure continuous improvement.

Conclusion
Attackers regularly evolve and often communicate with each other to do so. Incorporating the Scrum framework into
enterprise security processes enables security admins to develop and foster agile cybersecurity measures. This is critical
to enable them and their teams to become more nimble and continuously improve so that they can keep up with the
ever-changing threat and risk landscape.

-------------------------------------------------xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx------------------------------------------------

(https://www.ntaskmanager.com/blog/newbies-guide-to-scrum-project-management-101/)
What is Scrum made of?
The Team: Scrum teams are self-organizing teams, with 5 to 11 members. These teams need to be adaptive to change
and highly flexible. They also need to be cross-functional, with all proficiencies required to achieve the project without
dependency on team members. The Scrum team is divided as follows:
 
 Product Owner
 Development Team, and
 a Scrum Master.
 
Product Owner: The Product Owner is a single person, responsible for the Product Backlog, which is a list of features
that are prioritized with short descriptions of the functionality required. The Product Owner needs to ensure that the
Product Backlog elements are clearly stated and transparent to the team – about the current situation and what’s
planned next.
 
This means that the Product Owner should:
 
 Order the Product Backlog elements to best attain goals
 Help optimize the work value for the Development Team, and
 Ensure that the Development Team understands the elements of the Product Backlog.
 
Any suggestions regarding changes to backlog need to be addressed directly to the Product Owner.
 
Development Team: As the title implies, this team carries out the development work, which is incremented during the
sprints and potentially deliverable by the end of each sprint. This team is a disciplined, self-organizing and cross-
functional. In essence, it means the team members need to discipline their own work pace and be multi-skilled across
various functions. There are no titles, regardless of the level of work done by the team members; and there are no sub-
teams, regardless of domain diversity in domains e.g. testing, operations, analysis. The Development Team is
accountable for the whole for the work to be delivered.

Scrum Master: A Scrum Master is a facilitator and holds the responsibility for promoting and supporting Scrum. The Scrum Master
carries out employee coaching through Scrum – the theory, values, rules, and practices. The following are some of the ways a Scrum
Master can be of help to the entire team:
 
Scrum Master’s Service to the Product Owner: The Scrum Master can help the Product Owner by in some of the following ways:
 
 Making sure The Scrum Team understands the stated scope, product domain as well as goals
 Seeks effective methods for Backlog Management, and
 Help understand how to plan the project in an experimental setting.
 
Scrum Master’s Service to the Development Team: The Scrum Master can benefit the Development Team by:
 
 Training the Development Team in self-discipline and cross-functionality
 Minimizing roadblocks for the Development Team and maximizing value
 
Scrum Master’s Service to the Organization: The organization needs the Scrum Master to:
 
 Direct and guide the organization in its Scrum implementation
 Help staffs and stakeholders understand and endorse Scrum and empirical product development
 Pave way for maximum productivity of the Scrum Team, and
  Boost efficiency of Scrum application together with the other Scrum Masters.

The Events:
 

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of
“Done” product ensure a potentially useful version of a working product is always available.
 
Primarily, Scrum comprises 4 formal events or phases for review and adaptation: 
 Sprint Planning
 Daily Scrum
 Sprint Review, and
 Sprint Retrospective.
 
The Sprint, which is the main activity in Scrum, is a time-period lasting between 1 and 4 weeks. On average, the Sprint covers 2
weeks.
 
Sprint Planning Meeting: This meeting renders the activities that go towards planning exactly what needs to be done. Team
members take up different tasks based on the highest priority. The Product Owner and the Development Team then define the tasks
to be covered within the corresponding sprint.
 
Daily Scrum or Daily Standup: The Daily Scrum is an approximately 15-minute, daily event that highlights the activities of the team.
Each team member shares the work done the day earlier, work done that day and then identifies any problems. The purpose of this
daily meeting is to ensure all the team members are on the same page and their activities in sync.
 
Sprint Review: The Sprint Review is carried out at the end of each sprint where the team discusses and shows the goals achieved.
This review meetup also gives the stakeholders a chance to give feedback and suggestions about the product.
 
Sprint Retrospective: The Retrospective Meeting, also held at the end of the sprint, encourages the team to assess the goals
achieved. The team identifies the issues, weak or strong activities and ways for improving the new upcoming Sprint.

The Artifacts:
 Scrum Project Management stands on the 3 main artifacts that help focus on deliverability and business value. These are:  
 Product Backlog: The product backlog is a list of functionalities that are to incorporate in the deliverable. It is prioritized by
the product owner such so that the team can focus on the topmost requirements. This eliminates any confusion or time
wasted on unnecessary elements.
 Sprint Backlog: The Sprint Backlog is also a list of prioritized functionalities or activities that need to be done during the
corresponding sprint.
  Increment: The increment refers to the reviewable, authenticated work done at the end of the sprint. It denotes all the
Product Backlog items completed, combined with the value of the increments of all preceding Sprints. At the end of each
Sprint, the new Increment must be “Done” as per the Scrum Team’s definition. Different Scrum Teams can have different
ways to define “Done” depending on the required items to be completed. To ensure transparency throughout the project,
each team must understand the type and extent to which the tasks must be completed.

3. Other Use Cases and Applications for Scrum

The Scrum framework can be incorporated into multiple scenarios, especially when it comes to Information Technology. It can
contribute to effective team and project management resulting in proficiency in project monitoring and delivery.
 
 
3.1. Use Case 1: Web Development
 
Problem Statement: Important changes need to be carried out in an existing company website. The team needs to be assigned tasks
and timeline.
Actors:
 
Product Owner: Team Lead
Development Team: Developers
Scrum Master: Project Coordinator
Basic Flow of Events: 
1. The website needs to be updated under different categories.
2. The development team needs to be delegated the tasks and the timeline.
 
Using Scrum:
 
1. Product Owner creates a backlog i.e. the prioritized changes to make.
2. The development team and the QA team is created.
3. Sprint of 7 days is decided.
4. Scrum master is assigned to facilitate the meetings and issues.
5. Tasks are assigned to the team
6. A daily 15-minute Scrum is set up for holding team meetings
7. Each team member for both teams reiterates the tasks are done and those in the pipeline
8. Website is updated each day with the work done
9. QA notifies of issues on the same day.
10. Each week the Sprint Review meeting is held with the CEO for an update on progress.
  
3.2. Use Case 2: Game Development
 
Problem Statement: A client requires a game to be developed from scratch.
Actors:
Product Owner: Team Lead
Development Team: Programmers
Scrum Master: Project Coordinator
 
Basic Flow of Events:
 
1. The scope of the project needs to be defined within the time and budget.
2. The development team and the QA team need to be delegated the tasks and the timeline.
 
Using Scrum:
 
1. Product Owner creates a backlog i.e. the requirements and the most significant features to work on and the platform.
2. The development team and the QA team is created.
3. Weekly sprint is decided.
4. Tasks are assigned to teams
5. A daily 15-minute Scrum is set up for holding team meetings where each team member for both teams reiterates the tasks
are done and those in the pipeline
6. The Scrum Master coordinates between teams for the tasks being done.
7. The programmers provide update daily Scrum.
8. QA notifies of issues on the same day.
9. A weekly Sprint meeting is held to reinforce successful practices and eliminate unsuccessful ones
10. The product owner, the scrum master and the development team arrange to present a monthly Sprint Review to the
customer.
  
3.3. Use Case 3: Software Testing
 
Problem Statement: A client company is outsourcing Quality Assurance for its next online chat software.
Actors: 
Product Owner: QA Team Lead
Development Team: QA testers
Scrum Master: Project Coordinator
 
Basic Flow of Events:
 
1. The product needs to be explained to the testers.
2. Software testing methods and the platform is decided.
 
Using Scrum
 
1. Product Owner creates a backlog i.e. the most important application features to be tested.
2. Features to be tested are assigned to the QA team.
3. A sprint of 10 days is decided.
4. Daily Scrum of 20 minutes is planned for team updates.
5. Based on the updates, product owner re-assigns tasks or re-prioritizes testing.
6. The sprint meeting after 10 days is held with the client company.
7. Software bugs are reported daily and a report is made and sent by the Scrum Master to the client.
8. The programmers at the client-side update the software.
9. The monthly Sprint Review is held between the client and programmers and the QA teams.
10. A new backlog is created according to the changes in the software for the next Sprint.
 
 
3.4. Use Case 4: IT Support

Problem Statement: Customer issues are increasing and there is no standard plan for solving customer problems.
 
Actors:
Product Owner: IT Support Manager
Development Team: Support personnel
Scrum Master: IT Support Team Lead
 
Basic Flow of Events: 
1. Customer issues are communicated to the support team.
2. The support team communicates problems to the development team for improvements.
3. Problem log is created.
 
Using Scrum Project Management: 
1. Product Owner creates a backlog i.e. the most important issues the customers face.
2. The Scrum Master communicates the issues to the support team.
3. The support team communicates those issues to the programmers.
4. A daily, 20-minute scrum meeting with the Product Owner, support personnel and the Scrum Master.
5. A weekly sprint meeting is held to discuss the frequency of repeated issues with the support team and the programmers’
team.
6. A monthly sprint review meeting is held between the IT support manager, Programming Team Lead, Support team, and the
Programming Team.
(https://www.ntaskmanager.com/blog/newbies-guide-to-scrum-project-management-101/)