Athena.ecs.csus.edu
The Scrum Guide? The Definitive Guide to ScrumNovember 2017Developed and sustained by Scrum creators: Ken Schwaber & Jeff SutherlandThe Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:Clearly expressing Product Backlog items;Ordering the items in the Product Backlog to best achieve goals and missions;Optimizing the value of the work the Development Team performs;Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows whatthe Scrum Team will work on next; and,Ensuring the Development Team understands items in the Product Backlog to the level needed.The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is required at the Sprint Review. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.Development Teams have the following characteristics:They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.SUMMARY OF USER STORIES: THE THREE “C”S AND INVESTApril 15, 2015?Travis BirchLearning Objectives Becoming familiar with the “User Story”?approach to formulating Product Backlog Items and how it can be implemented to improve the communication of user value and the overall quality of the product by facilitating a user-centric approach to development.Consider the following User stories trace their origins to?eXtreme Programming, another Agile method with many similarities to Scrum. Scrum teams often employ aspects of eXtreme Programming, including user stories as well as engineering practices such as?refactoring, test-driven development (TDD) and?pair programming?to name a few. In future modules of this program, you will have the opportunity to become familiar enough with some of these practices in order to understand their importance in delivering quality products and how you can encourage your team to develop them. For now, we will concentrate on the capability of writing good user stories.The Three ‘C’sA User Story has three primary components, each of which begin with the letter ‘C’:CardThe Card, or written text of the User Story is best understood as an invitation to conversation. This is an important concept, as it fosters the understanding that in Scrum, you don’t have to have all of the Product Backlog Items written out perfectly “up front”, before you bring them to the team. It acknowledges that the customer and the team will be discovering the underlying business/system needed?as they are working on it. This?discovery?occurs through conversation and collaboration around user stories.The Card is usually follows the format similar to the one belowAs a <user role> of the product,I can <action>So that <benefit>.In other words, the written text of the story, the invitation to a conversation, must address the “who”, “what” and “why” of the story.ConversationThe collaborative conversation facilitated by the Product Owner which involves all stakeholders and the team.As much as possible, this is an in-person conversation.The conversation is where the real value of the story lies and the written Card should be adjusted to reflect the current shared understanding of this conversation.This conversation is mostly verbal but most often supported by documentation and ideally automated tests of various sorts (e.g.?Acceptance Tests).ConfirmationThe Product Owner must confirm that the story is complete before it can be considered “done”The team and the Product Owner check the “doneness” of each story in light of the Team’s current definition of “done”Specific acceptance criteria that is different from the current definition of “done” can be established for individual stories, but the current criteria must be well understood and agreed to by the Team. ?All associated acceptance tests should be in a passing state.The test for determining whether or not a story is well understood and ready for the team to begin working on it is the INVEST acronym:I – IndependentThe solution can be implemented by the team independently of other stories. ?The team should be expected to break technical dependencies as often as possible – this may take some creative thinking and problem solving as well as the Agile technical practices such as refactoring.N – NegotiableThe scope of work should have some flex and not be pinned down like a traditional requirements specification. ?As well, the solution for the story is not prescribed by the story and is open to discussion and collaboration, with the final decision for technical implementation being reserved for the Development Team.V – ValuableThe business value of the story, the “why”, should be clearly understood by all. Note that the “why” does not necessarily need to be from the perspective of the user. “Why” can address a business need of the customer without necessarily providing a direct, valuable result to the end user. All stories should be connected to clear business goals. ?This does not mean that a single user story needs to be a marketable feature on its own.E – EstimableThe team should understand the story well enough to be able estimate the complexity of the work and the effort required to deliver the story as a potentially shippable increment of functionality. ?This does not mean that the team needs to understand all the details of implementation in order to estimate the user story.S – SmallThe item should be small enough that the team can deliver a potentially shippable increment of functionality within a single Sprint. In fact, this should be considered as the maximum size allowable for any Product Backlog Item as it gets close to the top of the Product Backlog. ?This is part of the concept of Product Backlog refinement that is an ongoing aspect of the work of the Scrum Team.T – TestableEveryone should understand and agree on how the completion of the story will be verified. The definition of “done” is one way of establishing this. If everyone agrees that the story can be implemented in a way that satisfies the current definition of “done” in a single Sprint and this definition of “done” includes some kind of user acceptance test, then the story can be considered testable.Note: The INVEST criteria can be applied to any Product Backlog Item, even those that aren’t written as User Stories. 171 Spring 2018 ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.