Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
A Better Way of Working
What is Scrum? Scrum is a way for teams to work together to develop a product. Product development, using Scrum, occurs in small pieces, with each piece building upon previously created pieces. Building products one small piece at a time encourages creativity and enables teams to respond to feedback and change, to build exactly and only what is needed.
More specifically, Scrum is a simple framework for effective team collaboration on complex projects. Scrum provides a small set of rules that create just enough structure for teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge.
However, Scrum is much more than a simple framework. Scrum supports our need to be human at work: to belong, to learn, to do, to create and be creative, to grow, to improve, and to interact with other people. In other words, Scrum leverages the innate traits and characteristics in people to allow them to do great things together.
How Does Scrum Work?
Building complex products for customers is an inherently difficult task. Scrum provides structure to allow teams to deal with that difficulty. However, the fundamental process is incredibly simple, and at its core is governed by 3 primary roles.
Product Owners determine what needs to be built in the next 30 days or less.
Development Teams build what is needed in 30 days (or less), and then demonstrate what they have built. Based on this demonstration, the Product Owner determines what to build next.
Scrum Masters ensure this process happens as smoothly as possible, and continually help improve the process, the team and the product being created.
While this is an incredibly simplified view of how Scrum works, it captures the essence of this highly productive approach for team collaboration and product development. - Scrum.org
Is an essential artifact in Scrum. The Product Backlog is an ordered list of ideas for the product, kept in the order we expect to do them. It is the single source from which all requirements flow. This means that all work the Development Team does comes from the Product Backlog. Every feature idea, enhancement, bug fix, documentation requirement -- every bit of work they do -- is derived from a Product Backlog item. Each item on the Product Backlog includes a description and an estimate.
The Product Backlog may begin as a large list or a short one. It may be vague or rather detailed. Typically it begins short and vague and becomes longer and more concrete as time goes on. Product Backlog items slated for implementation soon will be "refined": clarified, better defined, split into smaller chunks, as part of the Product Backlog Refinement activity.
The Product Owner is responsible and accountable for maintaining the Product Backlog, although the Product Owner may -- and should -- have help in producing it and keeping it up to date. Product Backlog items may originate from the Product Owner, from team members, or from other stakeholders.
Each Sprint begins with a time boxed meeting called Sprint Planning. In this meeting the Scrum Team collaborates to select and understand the work to be done in the upcoming Sprint.
The entire team attends the Sprint Planning meeting. Working from the ordered Product Backlog, the Product Owner and the Development Team Members discuss each item and come to a shared understanding of that item and what is required to complete it consistent with the current Definition of Done. All Scrum meetings are timeboxed. The recommended time for the Sprint Planning meeting is two hours or less per week of Sprint duration. Because the meeting is timeboxed, the success of the Sprint Planning meeting is highly dependent upon the quality of the Product Backlog going in. This is why Product Backlog Refinement is an important Scrum activity.
In Scrum, the Sprint Planning meeting is described as having two parts:
The Sprint Backlog is the list of refined Product Backlog items chosen for development in the current Sprint, together with the team's plan for accomplishing the work. It reflects the team's forecast of what work can be completed.
With the Sprint Backlog in place, the Sprint begins, and the Development Team develops the new Product Increment defined by the Sprint Backlog.