SCRUMstudy™ webinar provides a platform for global professionals to interact with and learn from Scrum experts who share the best practices for successfully implementing Scrum in your organization.
6200+
Enrolled Participants
440+
Companies
206 mins
Average time spent by participants
99.68%
Average attentiveness
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.