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.