octobre 27, 2015
1) Is not a Product Owner responsibility: A- Running the daily scrum meeting B- Gathering requirements for Product Backlog items C- Working with stakeholders to determine and detail product features D- Inspecting work at Sprint Review Answer : A Explanation: All the other tasks are product owner responsibility except holding the daily stand up meeting & making sure that it has been run correctly. This is one of the Scrum Master responsibilities. 2) If More than one Scrum Team are working on a single project or a single release. How should the Product Backlog be arranged by the Product owner? A- A separate Product Backlog is constructed for each Scrum Team. All of the increments are integrated at the end in an integration Sprint. B- All Scrum Teams work from a common Product Backlog and integrate their work every sprint. C- Only one Scrum Team should work on Scrum project. D- Scrum Teams should have their separate Product Backlogs. Answer : B Explanation: When there are a number of Scrums considered, then there should be a high level of coordination & communication between the teams, which the Scrum of Scrums do. For the product backlog, it’s concerned with the Product, not the teams, nor the organization, so as long as the project is for one product, or the release is for one product, then one product backlog is considered. 3) The Product Backlog management include 1. Clearly expressing the different Product Backlog items 2.Authoring the various Product Backlog items 3. Ordering Product Backlog items by size and risk Only A- 1 and 3 only B- 2 only C- 1 and 2 only D- 1, 2, and 3 E- 1 only Answer : C Explanation: Product backlog management include expressing & elaborating on the different product backlog items, authoring those items, changing the prioritization of the backlog according to the Business value, and adding & deleting any further items. 4) Ali « as the Scrum Master of a Scrum Team » is invited for a Daily Stand-up meeting at 9am. During the meeting the whole team gets into a deep discussion and they finally start blaming each other. What should he do in such situation? A) Wait until people calm down again and continue with the meeting. B) Stop the discussions and continue with the meeting. C) Interrupt the meeting and continue it later that day. D) Discuss the situation with the team and decide together what to do to improve the situation. A- A B- B C- C D- C, D E- B, D Answer : B Explanation: He has to make everyone abide to the rules of the daily stand-up meeting, and the improvements or anything went wrong in the sprint shall be placed on the table during the Sprint retrospective meeting. 5) The Sprint Planning Meeting consists of __ session(s). A- One B- Two C- Three D- Four Answer : B Explanation: The Sprint planning meeting consists of 2 parts/sessions, the first one is for the Product Owner to elaborate more on the product backlog items & showing what he aims to accomplish in the coming sprint (setting the sprint goal), the second session is mainly for the team to plan, estimate & commit to the amount of work that they’ll finish during the coming sprint. 6) The Sprint Backlog is ultimately owned by: A- The Product Owner B- The Scrum Master C- The Stakeholders D- The Scrum Team Answer : A Explanation: The Scrum product owner is the person who is ultimately responsible& accountable for maintaining the Product/Scrum backlog, as he has to prioritize the items in the backlog mainly according to the return on Investment (ROI). 7) During a Scrum of Scrums approach for a project, what best defines the definition of « done »? A- Each Team defines and uses its own. B- Each Team uses its own but must make it clear to all other Teams. C- All teams must use the same definition. D- It depends. Answer : B Explanation: When considering the Scrum of Scrums, each Scrum team can use their own definition of done, but they have to make it clear to all other teams in order for all the teams to synchronize together their work at the end of each sprint, so they can consider each other’s DoD (definition of done) 8) What is the Time-box for a Sprint Review meeting if the Sprint was 2-weeks long? A- 15 minutes B- However long is needed C- 4 hours D- 2 hours at the end of every sprint Answer : D Explanation: The sprint review meeting is proportional to the sprint duration, it’s almost half the duration of the sprint planning meeting, and is proportional to the sprint duration 1:1, which means 1 week of sprint duration is equal to 1 hour sprint review meeting duration, 2 weeks sprint duration, means 2 hours sprint review meeting, and so on. 9) Which one is not a Scrum role? A- Product Owner B- Scrum Master C- Product Manager D- Team Answer : C Explanation: In Scrum, there are three roles only: the Product Owner, the Team, and the Scrum Master. All other roles like Project Manager; though can exist in the organization, but not a part of the scrum framework. 10) ___ constitute the Sprint Backlog and are normally estimated in hours. A- Stories B- Use Cases C- Features D- Tasks Answer : D Explanation: Tasks constitute the Sprint Backlog and are often estimated in hours. Alternate choices: Use cases are used for either requirements. A task may be to create use cases. Stories, also known as Storycards, are what may be used to document the product backlog item. Features requested by Product Owners are generally expressed in the Product Backlog as one or more story cards. 11) What best describes ‘time-boxed’ activity? A- There’s a target time limit for the activity. B- There’s a maximum time limit for the activity. C- The activity is planned to be delivered by a specified date. D- The activity must start on a specified date. Answer : B Explanation: Time-boxing means setting a time limit for the activity to end within that time limit, not later. If time extension is required, it’s ok to have an extension in some case (e.g. sprint review meeting), but not in other cases (e.g. Sprint, daily stand-up meeting), but all the participants in the activity shall know that the time-box has expired and they are working in the time extension, in order to limit themselves and their discussions accordingly. 12) The Release Burn down Is: A- A graph indicating what has been completed by the Scrum Team. B- What has been completed by the Scrum Team to date. C- The work remaining to be completed by the Product Owner. D- A measure of the remaining Product Backlog across the time of a release plan. Answer : D Explanation: The concept of a burndown chart is to measure how much work remaining roughly. The release burndown chart is not an exception. So it’s a way of measure of the remaining Product backlog across the time of a releaseplan. 13) The used metric to estimate with Planning Poker is: A- Numeric sizing (1 through 10) B- T-shirt sizes (XS, S, M, L, XL, XXL, XXXL) C- The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.) D- Person Hours E- Person Months Answer : C Explanation: The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.) is the metric used in all the designed planning poker decks. Though, some of those are deviating from the sequence a bit, but normally all the designed decks are following the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.) in some fashion. 14) Which of the following is a Scrum Value? A- Openness B- Fight C- Strength D- Quality Answer : A Explanation: Scrum values are five: Focus, Courage, Openness, Respect, Commitment. 15) What are the most critical items to start a Scrum Project? A. Scrum Team and Stakeholders B. Scrum Team, Product Backlog, Scrum Master C. Product Backlog, Scrum Team, Scrum Master, and Product Owner D. Time, Scope, Budget, and Quality A- A and D B- C C- A, B, and C D- A and B Answer : B Explanation: This is the answer where no duplications, and where all the required Scrum project components are available. To start a Scrum Project you’ll need to have a product backlog to define your product & the project scope, then the team to build that product, the maestro who will lead all that (scrum master), and the connection between those & the business who is accountable for the Return On Investment (ROI) ( product owner).
In one of our previous posts, we explained why Scrum Teams must create Done Increments in order to get a benefit from using Scrum. In this post, we'd like to dive a little deeper on what an Increment actually is.
"An Increment is a concrete stepping stone towards the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable." – Scrum Guide1 The term Increment can be confusing, especially to people who are new to Scrum or agile product development. To make this easier to understand, let's borrow a concept from software that we're all familiar with: versions. An Increment is the latest stable version of a product. "Latest" means that a product is being developed incrementally, with each Increment being an attempt to be more valuable than the previous one, for example through better functionality. "Stable" means that every Increment meets the Definition of Done and is usable by users. An Increment is the latest stable version of their product that is usable by the users. Let's look at some examples of Increments.
Here are some examples of Increments of various products:
Now, let's come up with some examples that aren't Increments:
These things aren't usable by or valuable for users. And you can't manage the 3 key-risks of product development through these things. Hence they can't be Increments.
The first Increment should be created right within the first Sprint in order to manage product development key-risks, especially the feasibility risk of the Scrum Team. This also prevents the Scrum Team from the fallacy of a "Sprint Zero" (to create the Product Backlog, the release plan, and the architecture) and the fallacy of "phased Sprints" (some Sprints to analyze, some Sprints to specify, some Sprints to build, ...). These two common misconceptions won't help use empiricism to create value and manage risks. The first Increment should be created right within the first Sprint. Some Scrum Teams and organizations that are not that experienced with Scrum say that a Scrum Team can't create an Increment during their first Sprint(s) as they will first have to create the product foundation or product architecture. While it's often necessary to spend a lot of time on creating a minimal foundation during early Sprints, a Scrum Team needs to create at least one feature every Sprint.
"Multiple Increments may be created within a Sprint. [...] Work cannot be considered part of an Increment unless it meets the Definition of Done." – Scrum Guide In order to manage the 3 key-risks of product development, Developers on a Scrum Team create at least one Increment per Sprint. They can, however, create many Increments within a Sprint, each Increment being an update of the previous Increment. Here's what this looks like:
While Developers create Increments, it's the Product Owner who decides when to deliver an Increment to users. Being accountable for that decision is essential, so the Product Owner can maximize the value of the product. The Product Owner can decide to deliver a single or multiple Increments per Sprint or decide to wait several Sprints, depending on her strategy to maximize value and manage the 3 key-risks of product development. When the Product Owner decides to deliver the Increment, it's important that it can be delivered to users without further effort. Everything else would cause a delay in time-to-market, potentially resulting in a lost opportunity to maximize product value.
"The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals." – Scrum Guide The work of a Scrum Team and their Developers can be broadly divided into three areas:
As part of discovering value, a Scrum Team and their Developers seek to learn more about the users, their needs and ways to create value. Their discovery work – for example, user research, competitor analysis, ideation, creating and validating hypotheses – might not become part of an Increment directly but helps the Scrum Team create and deliver valuable Increments as a result. Regarding the delivery of value, the Developers create and deliver Increments. Their work in this area – for example, designing, building and testing a product feature or improving the product quality by removing technical debt – directly results in a new Increment. To improve their effectiveness, a Scrum Team "identifies the most helpful changes" during a Sprint Retrospective. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint."1 These improvements might result in work for the Developers that doesn't add to an Increment directly but will help them become more effective in creating Increments. So, a Scrum Team can do work that doesn't result in an Increment directly, however, all their work should focus on the Product Goal and Sprint Goal in order to maximize value.
When multiple Scrum Teams work together to create a product, they create integrated Increments. This means that the work of all individual Scrum Teams is combined into an integrated Increment. If the Scrum Teams use the Nexus framework to scale Scrum, the Nexus Integration Team (NIT) is accountable that the Scrum Teams create an integrated Increment at least once every Sprint. Here's an example of what this might look like with three Scrum Teams in a Nexus:
Do you need help creating Increments regularly and delivering them to users earlier in order to manage your key-risks of product development? We help Scrum Teams create and deliver digital and physical products through Increments. So, let's talk. Let's talk!
References:
|
When there are multiple Scrum teams working on the same product should all of their increments be integrated every Sprint?
Postagens relacionadas
direito autoral © 2024 comojogaruno Inc.
