Average time spent by participants
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 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.
Scrum is not an acronym. The term is derived from the approach to product development propounded by Hirotaka Takeuchi and Ikujiro Nonaka in a 1986 Harvard Business Review paper. It is a holistic or rugby based approach because it involves cross-functional teams “going the distance as a unit, passing the ball back and forth.” The approach is based on manufacturing case studies from various industries. A scrum is similar to a scrimmage in American Football and is a method of restarting play in rugby after the game has been stopped.
Paired Comparison is a prioritization technique. In this technique, a list of all the User Stories in the Prioritized Product Backlog is prepared. Next, each User Story is taken individually and compared with the other User Stories in the list, one at a time. Each time two User Stories are compared, a decision is made regarding which of the two is more important. Through this process, a prioritized list of User Stories can be generated. You can read about more prioritization techniques in the SBOK® Guide or by going through our free Scrum Fundamentals Certified course.
Yes, it is basically a high level overview of what the stakeholders want to be delivered. The dates will be tentative. As and when we get closer to delivering the outputs, we can finalize the release schedule.
No, it will vary. For risky projects, where you do not have much experience, the sprint lengths should be shorter. For projects, where the requirements are stable and your team is mature enough, sprint lengths could be longer.
Epics are large user stories (requirements). For example, an Epic could be, "the ability to make payment online" which is a complicated requirement and would have to be broken down into user stories and from there into simpler tasks. There is no specific format for Epics, however, there is a format for user stories.
Yes, your items must fulfill Done Criteria before those could be added to your velocity. This does not mean that you handover products after every Sprint but Sprint deliverables should be in a potentially shippable state.
Well in that case, the Product Owner will have to define what “cosmetic issues” mean. Product Owner will define the severity and impact of the issues that could remain unresolved and even then features could be considered Done.
During Sprint Planning, the User Stories are taken up for discussion by the Scrum Core Team. If not already done during the Creation or the Grooming of the Product Backlog, each User Story is evaluated and assigned a high-level estimate based on relative story points. In Task Estimation, the Scrum Core Team estimates the effort required to accomplish each task in the Task List.
Scrum's transparency comes from openly viewable information tools like the Scrumboard, which shows the progress of the team. The team uses a Scrumboard to plan and track progress during each Sprint. The Scrumboard contains four columns to indicate the progress of the estimated tasks for the Sprint: a ‘To Do’ column for tasks not yet started; an ‘In Progress’ column for the tasks started but not yet completed; a ‘Testing’ column for tasks completed but in the process of being tested; and a ‘Done’ column for the tasks that have been completed and successfully tested.
Yes, the Sprint will have to end. Time is one constraint that you have to follow. The unfinished work is then prioritized against the remaining requirements and a new Sprint is planned. Also, the team will have to rethink about their velocity.
If the whole team is not familiar, you can hire a Scrum Master who is familiar with the framework. And once the team understands the framework, you can choose a Scrum Master from among any of the team members. You can at least get your team trained in the free Scrum Fundamentals Certified course to get them all on the same page.
Yes, soft copy of the SBOK® is free to download. Please use the link : https://www.scrumstudy.com/sbokguide/download-free-buy-sbok to download the SBOK® guide.
Yes, it means that the Scrum team organizes itself. What it entails is that a Scrum team is told what has to be done but they decide how it should be done. There is no Project Manager in Scrum project to manage them. They manage themselves and they estimate their own work.
You can only have a set budget for a project when your scope is well defined. Scrum is more suited for projects where you are expecting a lot of change and as such you cannot come up with a project budget at the beginning of a project because project requirements are going to change as you move forward.
Agile is a group of product and service development techniques using an iterative and incremental approach in which solutions are delivered in stages. Scrum is the most popular Agile framework to deliver projects successfully.
You can have a look here: https://www.scrumstudy.com/classes/scrum-certification-training
You can use your centralized configuration management system to store sprint documentation for future reference depending on your organization policies on project management.
Scrum framework is best suited for research oriented projects due its flexible nature. As long as you have the organizational buy-in, there is not much tailoring required to apply Scrum for grant funded projects.
There is a concept called Scrum of Scrums meeting which enable project teams to handle interdependencies and resource sharing & allocation. This will be discussed later in the webinar.
Scrum can be applied in any industry, however, it is best suited for projects which have high uncertainty as the flexible approach helps the teams deliver results quickly and efficiently.
Hi Jairo, that is a good question and you might get some idea once the presentation is done. We could probably discuss it offline. Please drop an email to email@example.com and we can talk about it. But almost every software company has migrated to or is migrating to the Scrum framework. It is much more efficient and project delivery is much more successful.
Yes, it will be covered when we discuss Scrum principles but basically, time is a constraint in a Scrum project and all activities are time-bound/time boxed.
Scrum of Scrum meeting is overseen by Chief Scrum Master and attended by all the Scrum Masters and any other team members who are required for the meeting.
It will be determined by the Scrum Team depending on their velocity. However, the Product Owner will sign it off.
When the requirements are stable and uncertainty is less, you can have a longer sprint duration. But it is recommended to cap the sprint to 4 weeks.
Well it is not as formal as in traditional project management. Changes are welcome in a Scrum project. But, it would still be assessed for priority based on the business value by Product Owner and then added to the backlog.
Generally, it doesn't. But if rare cases, the Product Owner and the scrum team may decide to change the length of sprint.
Completion of a project is not important, what is important is achieving project objectives - a working software as opposed to just fulfilling project documentation.
It will be considered as a new Sprint. You may involve the stakeholders if necessary but Product Owner, Scrum Master and Scrum Team need to be in agreement.
Actually, you do not necessarily need a software to do it. Scrum projects can easily be managed with Google spreadsheet. JIRA is a popular tool used by Scrum teams.
You cannot have a fixed price project if your scope is going to change depending on changing requirement. And honestly, in how many projects, the customers know exactly what they want at the beginning of a project? It is one of the reasons for project not being able to deliver what the customer wants.
These will be briefly discussed in the presentation. You can read more about it in our SBOK® Guide: https://www.scrumstudy.com/sbokguide/download-free-buy-sbok
Allow them to self-organize and keep the communication channels open. Daily standup meetings and Sprint planning meeting are really important. SBOK® Guide has a lot of tips on self-organization. Please go through those for more ideas.
You can read about it in detail here: https://www.scrumstudy.com/blog/scrum-story-points/
Unless all the team members adhere to Scrum principles, you are not using Scrum framework.
We don’t create separate backlogs for risks. The prioritized product backlog will have a section or column for risks and the associated management action. The product backlog will be created at the beginning of the project.
Not unless it a project requirement in your case. Those get added to the backlog.
Product owner is accountable for this but he/she can delegate it to other team members.
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 organizations, BAs end up taking requirements from the PO and explaining to the Scrum team.
There is no specific role that manages risks. Depending on the level of risk, it will be handled by the Scrum Team or Product Owner or escalated to programme or portfolio management.
It is the responsibility of the Product Owner to update the Business Case. Apart from regular updates, Business Case is updated in case there is an event that might affect the viability of the project.
No, you do not need a lot of documentation to deliver Scrum projects. It is minimal, depending on your own requirement. You basically need a product backlog and a scrumboard.
Sprint projects work on the basis of business value prioritization. So, Product Owner has to decide if a bug fixing is more important than development of a new feature and based on that resources are allocated.
Budget will be signed off when the business case is approved. Business case will help the scrum team to get buy-in from the sponsors.
Please find the details here: https://www.scrumstudy.com/classes/scrum-certification-training
Yes, apart from Grooming activities, rest are done as part of Sprint planning meeting. For a 4 week sprint, sprint planning meeting is time boxed to 8 hours of the Sprint.
Product owner but he/she can delegate this work.
The Scrum Team but approved by the Product Owner.
Scrum does not recommend multi-tasking. But at the end of the day, it is about value based prioritization. If your stakeholders and Product Owner think that the resources can give more value in other project, they would assign resources accordingly. It might require a conversation between the Scrum Master and the Product Owner.
It depends on the importance of the deliverable, if it is an essential product required for development of other project deliverables then it will be reprioritized for the next sprint.
There is no standard as such. It depends entirely on the nature and size of the project.
It should follow this sequence - a high overview of Release Planning and then you have your epics in the backlog, broken down into user stories and tasks.
A Stakeholder is anyone who can impact, or who is impacted by or who thinks he is impacted by the project. He may or may not be part of the core Scrum team but who could impact the project.
Technical knowledge is not mandatory but it can be advantageous. There are actually studies where it has been shown that non-technical Scrum Masters have proven to be much more successful than technical ones.
Daily meetings are imperative for transparency and collaboration without which Scrum framework will not deliver expected results.
Yes, it means it is still too big and needs to be broken down. Also, the longer the duration, the less accurate your estimate is generally going to be.
Yes, it generally will. But in case of large projects, it can have pointers to where detailed descriptions are available.
If it is a new project for the organization, it will generally take longer. For mature teams and familiar projects, the duration is shorter.
His function is to facilitate the team to deliver projects and help remove any impediments they might be facing. He is the servant leader.
The organization will have to appoint a new Product Owner. Scrum projects cannot function without a close collaboration between Product Owner and the development team.
Yes, this can be done, depending on the situation of the project. Generally, you do not have much gap from one Sprint to another. Also, please remember that Scrum does not recommend multi-tasking.
There is one representative in the Scrum of Scrums meeting from each Scrum Team—usually the Scrum Master—but it is also common for anyone from the 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.
Hi Elizabeth, in a Scrum project, decisions are made based on business value. If a team member leaves and is not replaced, why is that so? Does this mean that the team thinks that they do not need a replacement or does the Product Owner and the Customer think that the additional resource will yield higher business value elsewhere? If the Scrum Team thinks that they actually need a replacement then they need to talk to the Scrum Master and the Product Owner about it.
Yes, when assessing a risk its proximity, impact and probability are considered.
As this is an introductory Webinar and training, we will not be able to answer this question in complete detail but by the time the presentation is over, you will have a fair idea about it. I think the main integration point is management vs. delivery. Scrum is more to do with delivery of the project while traditional Project Management is more about management.
Epics are large user stories (requirements). For example, an Epic would be, "the ability to make payment online" which is a complicated requirement and would have to be broken down into user stories and from there into simpler tasks.
Every Sprint will have potentially shippable deliverables at the end which may or may not be shipped. A Sprint is a time-boxed iteration to deliver user stories.
Fixed price contracts are only applicable for projects where scope is fixed with minimal expected change. Scrum is best suited for projects where scope is not well defined and is expected to change with changing customer requirements. However, it can be used to deliver all types of projects including fixed price projects. For example, in a fixed price project, the teams can use Scrum framework to deliver the outputs in an iterative and incremental way. Any improvements that can be achieved by going beyond the terms of contract can be negotiated between the supplier and the customer during project execution. Or they can agree clauses within the contract that would grant the supplier enough freedom to products using the Scrum framework.
You cannot implement a major change without assessing its impact on the key project objectives. So, you need to make the customer aware of the impact of a change and get their approval before implementing the change.
You certainly can. Actually, even PMI is coming out with Agile handbook with its 6th edition of PMBOK® Guide.
Hi Rashmi, it depends on the job market you are looking at. Generally, people with project management/delivery certifications are preferred to those who do not possess the certifications in the project management job market.
You can begin with Scrum Developer Certified and then scale up to Scrum Master Certified and other advanced level certifications.
Yes, it will be uploaded to the SCRUMstudy™ website. You will also get a link to the recorded webinar through email.
Project vision explains the business need the project is intended to meet rather than how it will meet the need. However, the Project Vision Statement should not be too specific and should have room for flexibility. It is possible that the current understanding of the project may be based on assumptions that will change as the project progresses, so it is important that the project vision is flexible enough to accommodate these changes. The project vision should focus on the problem rather than the solution.
This is done through the business justification. Kindly refer to the Business Justification section in the SBOK® Guide. You can download it for free here: https://scrumstudy.com/sbokguide/download-free-buy-sbok
I think you mean Scrum Ceremonies. We will be discussing details as we move on in the presentation but there are four Scrum ceremonies or meetings: Sprint Planning Meeting, Daily Standup, Sprint Review Meeting, and Sprint Retrospect.
Yes, there can be planning and estimation for every new sprint. Even though it might seem like a linear structure, Scrum processes are not linear, they are iterative.
The SBOK® Guide is reviewed every year and a new version is released when there is a significant update to the concepts. The last update happened in 2017 where separate sections on Scaling Scrum for Large Projects and Scaling Scrum for the Enterprise were added.
Please refer to the SBOK® Guide – Table 1-3, Page 20 for more details.
Preferably yes but in today’s environment where distributed teams are becoming more common, Scrum Master might use web-conferencing tools too.
There are multiple software tools such as JIRA and Rally.
Focusing on the needs of the team refers to minimizing barriers to creation of deliverables. In this regard, servant leadership implies that the team takes the lead in ensuring that obstructions or impediments are resolved by themselves. And they escalate issues only when they are unable to resolve issues themselves.
Yes, whoever provides requirements and uses the end products are customers.
There is no certificate of completion. However, you can achieve SFC™ certificate by passing the SFC™ exam. You can schedule and take the exam by logging into VMEdu® online course provided to you.