It depends on the Scrum Team, they can use whichever tool they are comfortable with. Scrum is not fixated on any specific tool. The only requirement is that it should be transparent and accessible to all team members.

Yes David. You will need to enroll using this link for the SFC^™ certification - https://www.scrumstudy.com/certification/scrum-fundamentals-certified

You can take it at any time of your choice. This is the link to register for the certification - https://www.scrumstudy.com/certification/scrum-fundamentals-certified

We believe in contributing to the Scrum/Agile community. We conduct these free Webinars/Training to propagate the practice of Scrum and to help people deliver project successfully. You can ask questions here. We will answer it through chat. The presenter may select some questions for answering too.

Value is the business value e.g. which business requirement provides better return on investment.

It is similar to a stage but it is governed differently. Key difference is each sprint will have a potentially shippable deliverable however each stage/phase/activity may not have.

SCRUMstudy^™ and PMI are two different certification bodies with different certification schema.  SBOK^® is widely accepted and recognized and is being used by all major corporate worldwide. SBOK^® defines Scrum framework which is the most popular Agile framework. PMI Agile Practice guide covers the different Agile approaches and is not focused only on Scrum. SCRUmstudy offers a similar certification named SCRUMstudy Agile Master Certified. You can read about it here: https://www.scrumstudy.com/certification/agile-certification

You will get a good idea as we go through this session. For example, in some vendor projects where I was involved with, we had several Scrum teams in the vendor organization who were coordinating with a Product Owner in our company. In today’s scenario colocation is not always possible but in such situations you need to leverage technology to enable communication amongst team members for meetings such as daily standups.

The pass percentage varies but on an average it is close to 90%. You can retake the SFC^™ exam as many times as you require for free.

If you mean technical requirements, that is where writing requirements in terms of user stories come handy. User stories are writing in terms of business requirements and as such it is easier to explain to stakeholders.

They are based on Agile principles but not the same. These principles are specific to Scrum. You can refer to Chapter 2 in the SBOK^® Guide for more details.

Product Owner is generally from the sponsoring organization. He/she is the voice of the customer. A sponsor may or may not be intimately involved in the project but a Product Owner has to be involved.

Depending on the type of project and the deliverables being developed, a Business Analyst can be a Scrum Developer, Scrum Master or even a Product Owner. In some situations, the requirements are given to the Business Analyst who then explains it to the Product Owner.

Product Owner cannot also be the Scrum Master due to conflict of interest. Yes, if the functional managers or Project Managers have Scrum expertise, they can be Scrum Masters.

A business case may be a well-structured document or simply a verbal statement that expresses the rationale for initiating a project. It may be formal and comprehensive, or informal and brief. Regardless of format, it often includes substantial information on the background of the project, the intended business purpose and desired outcomes, a SWOT and Gap analysis report, a list of identified risks, and estimations of time, effort, and cost. The project commences with the presentation of the Project Business Case. A business case is presented to the stakeholders and sponsors. The stakeholders understand the expected business benefits of the project and the sponsors confirm that they will provide the financial resources for the project.

Yes, it is the Product Owner who approves or rejects a product/feature based on the Acceptance Criteria.

Yes, both mean the same.

There was no BOK for Scrum until the SBOK^® Guide was introduced. The framework was contained in experiences of Scrum practitioners. The SBOK^® Guide was developed through the use of combined knowledge and insight gained from thousands of projects across a variety of organizations and industries. In addition, contributions have been made by experts who have taught Scrum and project delivery courses to more than 400,000 professionals in 150 countries. For more details, please visit - https://www.scrumstudy.com/whyscrum/why-scrumstudy-training

One feature (user story) cannot be developed over multiple sprints. They need to be broken down into simpler user stories that could be delivered in one Sprint.

The Daily Standup Meeting is a short daily meeting, Time-boxed to 15 minutes. Team members assemble to report their progress in the Sprint and plan the day’s activities. The meeting duration is very short and all members of the Scrum Team are expected to attend. However, the meeting is not cancelled or delayed if one or more members are not able to attend.

The three questions discussed during a Daily Standup Meeting are: 1) What have I done since the last meeting? 2) What do I plan to do before the next meeting? 3) What impediments or obstacles (if any) am I currently facing?

The certificate is administered by us only (i.e. SCRUMstudy^™) and the SFC^™ certificate does not expire. For details of other SCRUMstudy^™ certifications, request you to check this link: https://www.scrumstudy.com/certification

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. It is important to note that any item in the Prioritized Product Backlog is always open for re-estimation until the Sprint Backlog is finalized in the Create Sprint Backlog process. After that, changes can continue to be made until immediately prior to the Sprint Planning Meeting, if required.

Yes, it can work with the help of an experienced Scrum Master. As mentioned before, even though Scrum started with software industry, it has evolved into a framework which is applicable to any type of industry.

Accountability is with the Product Owner but it will generally be the scrum team who does this.

We will discuss this when we go through the Changes chapter later in the presentation. Broadly, approved changes are added and prioritized into to the prioritized product backlog as new user stories. They can be implemented in future sprints.

No, it is not recommended because of the inherent conflict of interest between the two roles.

Scrum discourages multi-tasking. There are multiple researches that show that multi-tasking reduces your efficiency. You cannot at times stop team members working on multiple projects due to business considerations but it is not recommended.

Product Owner is the voice of the customer. Anybody who can represent the customer can be the PO.

Hi Greg, all the changes that you receive have to be prioritized based on the business value that a business will derive from implementing those changes. For example, for a new landing page, the business value could be more traffic to the webpage resulting in more conversions/revenues for the business. It is for the business to determine, which change requests should be prioritized based on their respective business values. There are different prioritization techniques such as paired comparisons, MoSCoW technique, planning poker, etc. These will be discussed later in the presentation.

Yes, if the Project Manager has the knowledge of Scrum. Actually, that is how the evolution is happening for the Project Manager role.

POs are chosen by the Senior management of the organization sponsoring the project. Scrum Masters are chosen by the Product Owner in consultation with other stakeholders.

The Scrum framework specified by the SBOK^® Guide can be applied to all Scrum practices.

Yes, the Scrum Master can escalate the issue to the Product Owner if it is related to project deliverables.

Yes, you can understand Scrum Guidance Body as being similar to the PMO. Scrum Guidance Body (SGB) is an optional role, which generally consists of a set of documents and/or a group of experts who are typically involved with defining objectives related to quality, government regulations, security, and other key organizational parameters. This SGB guides the work carried out by the Product Owner, Scrum Master, and Scrum Team.

Scrum Coach role is similar to that of a Scrum Master.

A Release Planning Schedule is one of the key outputs of the Conduct Release Planning process. A Release Planning Schedule states released which deliverables are to be to the customers, along with planned intervals, and dates for releases. There may not be a release scheduled at the end of every Sprint iteration. At times, a release may be planned after a group of Sprint iterations are completed. Depending on the organization’s strategy, Release Planning sessions in projects may be driven by functionality, in which the objective is to deliver once a predetermined set of functionality has been developed, or the planning may be driven by date, in which the release happens on a predefined date. The deliverable should be released when it offers sufficient business value to the customer.

Vendors include external individuals or organizations that provide products and services that are not within the core competencies of the project organization.

The optimum size for a Scrum Team is six to ten members—large enough to ensure adequate skill sets, but small enough to collaborate easily. A key benefit of a six-to-ten-member team is that communication and management are typically simple and require minimal effort. It is important for the Scrum Team to possess all the essential skills required to carry out the work of the project. It is also necessary to have a high level of collaboration to maximize productivity, so that minimal coordination is required to get things done.

Yes, each team should ideally be following Scrum and using it to deliver projects. Although, based on your question, it seems your team members are multi-tasking (working on different projects simultaneously). Scrum actively discourages multi-tasking.

Kindly refer to sections 3.4 and 3.5 in the SBOK^® Guide.

There cannot be more than one Product Owner in a Scrum project otherwise there will be a lot of confusion and conflicts in prioritizing requirements.

SoS meetings are event based. As and when there is need for collaboration and coordination among different Scrum Teams, the Chief scrum master can call for a SoS meeting.

Ideally there should not be any multi-tasking in a Scrum project but in reality Scrum Masters end up working in multiple projects.

A Scrum of Scrums Meeting is an important element when scaling Scrum to large projects. Typically, there is one representative in the meeting from each Scrum Team—usually the Scrum Master—but it is also common for other members of a Scrum Team to attend the meeting if required. This meeting is usually facilitated by the Chief Scrum Master and is intended to focus on areas of coordination and integration between the different Scrum Teams.

User Stories adhere to a specific, predefined structure and are a simplistic way of documenting the requirements and desired end-user functionality. A User Story tells you three things about the requirement: Who, What, and Why. The requirements expressed in User Stories are short, simple, and easy-to-understand statements. User Story Format: As a , I should be able to so that . User Story Example: As a Database Administrator, I should be able to revert a selected number of database updates so that the desired version of the database is restored.

The list of the tasks to be executed by the Scrum Team in the upcoming Sprint is called the Sprint Backlog. It is common practice that the Sprint Backlog is represented on a Scrumboard or task board, which provides a constantly visible depiction of the status of the User Stories in the backlog. Also included in the Sprint Backlog are any risks associated with the various tasks. Any mitigating activities to address the identified risks would also be included as tasks in the Sprint Backlog.

Yes, as long as you adhere to Scrum principles, you can use Scrum to deliver implementation projects too. Break down the requirements and ensure that there is a feedback loop.

A Scrum team may or may not have a Business Analyst to begin with. If a Scrum team has a business analyst and their role is over, they can be released to other projects or they could go back to their functional roles.

The responsibility of prioritizing and delivering business value in an organization for projects lies primarily with the Product Owner. Product Owner is responsible for creating business justification for projects and for confirming benefit realization to stakeholders

This has a lot to do with team maturity. It takes time for a team to grasp the meaning of self-organization. They will need more coaching to understand the value of self-organization and how it is their responsibility to estimate and commit to a Sprint. As for Pharma industry, if it is a requirement of a particular industry, you will have to comply and figure out ways to integrate Scrum principles with regulatory requirements.

It will be undertaken at the end of every sprint to enable the Product owner and stakeholders to accept or reject the deliverables. Please try to understand that testing is part of a Sprint. When a user story is estimated, that estimate should include time and resources required for testing too. That is why, a Scrum team should include resources for testing too.

The flexibility is what allows you to remain on track. After every iteration you get the feedback from relevant stakeholders as to how much close you are to the actual requirement of customers. Problems occur when the customer is not involved and you are not getting constant feedback. The iterative development principle takes care of this.

A user story is not considered “Done” unless it has gone through testing too. As such you cannot claim to have finished a Sprint satisfactorily unless your products are Done. If that is not the case and a user story is not Done, then the next Sprint will reprioritize the left over user stories with this user story which was not done.

A fixed price contract can only work if the scope is more or less fixed and you do not anticipate much changes. A Scrum project tends to be meant for projects where there is not much clarity on Scope and the teams expect a lot of changes as the project moves forward. As such fixed price contract will not generally work with Scrum projects.

Hi Ned, even in the case of Scrum projects, change are not incorporated without any thoughts. The Product Owner when confronted with change requests will have to assess it against the cost/benefit analysis and only if the business value resulting from the change makes sense, it will be approved. Also, once a Sprint has started, the scope of the Sprint cannot be changed unless the Product Owner is ready to take the burden of getting a Sprint cancelled. What also goes in favor of Scrum is the in-built transparency in its processes. You cannot hide many things in Scrum.

Please refer to section 3.10.4.1 in the SBOK^® Guide for more details.

Each User Story will have associated User Story Acceptance Criteria (also referred to as “Acceptance Criteria”), which are the objective components by which a User Story’s functionality is judged. Acceptance Criteria are developed by the Product Owner according to his or her expert understanding of the customer’s requirements. Acceptance Criteria should explicitly outline the conditions that User Stories must satisfy. At the end of each Sprint, the Product Owner uses these criteria to verify the completed deliverables; and can either accept or reject individual deliverables and their associated User Stories.

Quality in Scrum is ensured through: Deliverables which meet the User Story Acceptance Criteria are accepted by the Product Owner. The objective of a Sprint is to create potentially shippable deliverables, or product increments, which meet the Acceptance Criteria defined by the customer and Product Owner. These are considered Accepted Deliverables that may be released to the customer if they so desire. A list of Accepted Deliverables is maintained and updated after each Sprint Review Meeting. If a deliverable does not meet the defined Acceptance Criteria, it is not considered accepted and will usually be carried forward into a subsequent Sprint to rectify any issues. This is highly undesirable because the objective of every Sprint is for the deliverables to meet the criteria for acceptance.

The SBOK^® Guide doesn't define any typical formats for Acceptance Criteria as it does for User Story. But one condition is that every acceptance criterion should be objective and measurable.

It is managed through the prioritized product backlog. Valid change requests are added to the backlog and the PO determines the priority.

It will be easier if the said vendor also follows Scrum. At the end of the day, changes would have its own cost and as such every change that is approved should be assessed in terms of cost vs. benefit. Only if the business value of the change is more than the costs associated, the change request should be incorporated in the Prioritized Product Backlog.

There is no separate artefact for documenting change. It is done through the Product Backlog.

Once a Sprint has started, you cannot change the scope of the Sprint which means user stories once committed to by the teams for a particular Sprint cannot be changed without canceling the Sprint.

The PO will have to take a decision if the Sprint needs to be cancelled and a new sprint planned to incorporate that change. The PO has to make it explicitly clear to the stakeholders the cost of each of these change requests.

The sprint backlog is created by the Scrum team with the help of the Scrum Master. There is no formal sign-off for the Sprint backlog by the PO. It is for the Scrum Master and the Scrum team to decide.

You can use a Change Request form or any documentation defined in your company to capture the change request.

There could be a number of factors that could determine if a change request is urgent or not. For example, the impact of a change request on the user stories being worked on. If you realize that the user stories being developed will not fulfil the customer requirements unless this given change request is implemented, you might want to prioritize the change requests higher.

No backlog does not mean being behind in the project. "Prioritized Product Backlog" is a technical term to define where user stories are written and prioritized. As oxford dictionary defines a backlog being “an accumulation of uncompleted work or matters needing to be dealt with”, a product backlog is a list of tasks which need to be finished.

The impact is assessed by the Product Owner with the help of the team and based on that a decision is taken, first to approve or reject a change request and then to prioritize it and add to the prioritized product backlog.

The sprint is cancelled and a new sprint is planned for the reprioritized user stories. Once a Sprint starts, the scope of the Sprint cannot be changed.

Tools to access risk are similar to tools used for risk in other projects. Few techniques are pareto analysis, probability trees, probability impact grid, etc. Details are available in the SBOK^® Guide Risk Chapter. You can download and review for free. https://www.scrumstudy.com/sbokguide/download-free-buy-sbok

It will depend on the format you are using for the product backlog. Yes, risk and associated user story should be linked. And it is always a good practice to document identified risks. You can do it with JIRA too.

It depends on skills, availability of the personnel for the duration of the project, commitment, etc. You can read about the selection criteria in the SBOK^® Guide. You can download and review for free. https://www.scrumstudy.com/sbokguide/download-free-buy-sbok

Personas are not mandatory but they are very useful to the teams developing features as they are used to represent user groups to the Scrum Team.

Few of the processes from the Initiate phase will repeat but not all. For example, writing Epics might be iterative because of new requirements but you might not need to develop a Vision Statement again. You might have to keep on updating the release planning schedule as you move ahead in the project too.

Epics are written in the initial stages of the project when most User Stories are high-level functionalities or product descriptions and requirements are broadly defined. They are large, unrefined User Stories in the Prioritized Product Backlog.

Here are the links Chetan - SBOK^® Guide – Log in to your online account and download SBOK^® Guide. Go to ‘Reference Materials’ section in the  Scrum Fundamentals Certified (SFC^™) course: https://online.vmedu.com  Course Presentation – Download the course presentation here: https://goo.gl/vQQ39J  Process Chart – Download the process chart here: https://goo.gl/Hbh3Jv

A persona is a real-life person using the system or being impacted by the migration.

User stories are estimated as part of the process Estimate User Stories in the Plan and Estimate Phase. Once you have broken down the user stories into tasks, Estimate tasks will be used to estimate tasks too.

Prioritized Product Backlog contains a prioritized list of business and project requirements written in the form of Epic(s), which are high level User Stories. The Prioritized Product Backlog is based on three primary factors: value, risk or uncertainty, and dependencies. The list of the tasks to be executed by the Scrum Team in the upcoming Sprint is called the Sprint Backlog.  It is common practice that the Sprint Backlog is represented on a Scrumboard or task board, which provides a constantly visible depiction of the status of the User Stories in the backlog.

Different teams estimate differently although estimation in terms of relative sizing (story points) has become very popular. Story points can be used for estimating the overall size of a User Story or feature. This approach assigns a story point value based on an overall assessment of the size of a User Story with consideration given to risk, amount of effort required, and level of complexity. This assessment will be conducted by the Scrum Team and a story point value will be assigned. Once an evaluation is done on one User Story in the Prioritized Product Backlog, the Scrum Team can then evaluate other User Stories relative to that first story.

Effort estimated task list is maintained by the Scrum team.

In that case, you start by getting all of them speak the same vocabulary. That can easily be done by getting your team to go through our Scrum Fundamentals Certified (SFC^™) training, the one which you are attending. For more specialization, some of them could go for higher level certifications and training.

You certainly can. You could have Themes under which you could put Epics and then related User Stories. There is  no set rule for it, whatever makes it convenient for the teams.

Unlike Traditional PM, Scrum accepts changes. Product Owner (who represents the customer) can make changes to the PPB regularly and prioritize requirements. In traditional PM, changes are not allowed easily and usually, scope has to be defined and documented in the beginning (which takes a lot of time, and may not be useful since all requirements may not be known at project initiation). Scrum is an iterative Agile approach and is quickly replacing traditional PM in most companies.

POs do not necessarily need to be part of daily standups but if they want to, they can.

It can be any of the Scrum Team members or they can ask for help from the Scrum Guidance Body.

It is a common issue mentioned by most project leaders. The trick is to make members feel involved and for them to realize that their suggestions are not being thrown into the bin but are actually put to use.

There is no minimum number on the number of releases. However, every sprint should have potentially shippable deliverable.

The Scrum Core Team members and relevant Stakeholder(s) participate in Sprint Review Meetings to accept the deliverables which meet the User Story Acceptance Criteria and reject unacceptable deliverables. These meetings are convened at the end of every Sprint and Scrum core team members associated with that Sprint should ideally attend it.

The question that Scrum Master should ask in such a situation is, “Why is nobody ready to accept this particular task” and then try to remove that impediment. It could be because the requirements are not clear or the skill sets required for the development is missing. PO can certainly revisit the team structure and take advice from the Scrum Master if the teams need a change in personnel based on the skill sets required.

Potentially shippable product increment and potentially shippable product increment are one and the same. Yes, every sprint should have potentially shippable product increment.

There are a number of cost/budgeting tools discussed in the SBOK^® Guide. Kindly download and refer to it but you need to understand that the costing in a Scrum project will not work like in a traditional scenario. You cannot come up with budget at the beginning of a project when you are expecting the scope to go through frequent changes.

Scrum team is a cross functional team so they need to have the required skills to develop the solution.

Scrum teams are self-organized who motivate themselves to deliver results as they are collectively responsible for success or failure of the project. In practice, Scrum processes are intrinsically transparent. So, every morning during a daily standup, every member will have to give an update of what they have done and what they intend to do. It is really difficult to hide for long in such a situation.

But that is the inherent difference between a command and control approach of a traditional framework vs. the self-organized teams of a Scrum project. It requires time and a lot of coaching but once a team understands the value of self-organization and gets self-motivated, you do not need an authoritative power to manage them.

At the end of the day, it is all about business value. The project and its stakeholders need to take decision based on the value generated.

Cooperating means working with someone in the sense of enabling: making them more able to do something (typically by providing information or resources they wouldn't otherwise have). Collaborating means actually working alongside someone (from Latin laborare: to work) to achieve something.

Teams need not be collocated so as long as they can talk with each other through video conferencing or other tools on a regular basis.

Velocity represents the number of User Stories or number of functionalities delivered in a single Sprint.

It doesn't have to be a person or group. You can use an entity as well as long as you are able to capture the requirement in an objective manner.

Yes, if at the end of the Sprint you were able to deliver both the user stories and both are accepted by the Product Owner based on the Acceptance Criteria, your velocity is 5.

Yes, a Sprint Planning Meeting is time-boxed. For a one month Sprint, Sprint Planning Meeting is time-boxed to 8 hours.

You can access the online course in your SCRUMstudy^™ student portal. It has high quality videos, study guides, chapter tests and all. They would be sufficient to prepare for the SFC^™ certification exam.

If you do not pass in the first attempt, you can re-take the exam again any number of times.

The certificate is administered by us only (i.e. SCRUMstudy^™) and the SFC^™ certificate does not expire. For details of other SCRUMstudy^™ certifications, request you to check this link: https://www.scrumstudy.com/certification