Scrum Usage Instructions
Please open your packaged Scrum and empty the contents in an open place in your office. Please find the following packaged with your new Scrum
1 x Scrum Team
+ 3-9 x Development Team Members
+ 1 x ScrumMaster
+ 2 x Product Owner
Assembling the Scrum Team
There are many ways to assemble a Scrum Team. The required parts were included by the supplier of your new Scrum, but it is up to the consumer to arrange the parts of the team to suit your specific needs. These instructions should prove valuable in assisting you to configure your Scrum Team.
Regardless of the skills needed to develop your product, our advice will always remain – to get the most out of your product development efforts, ensure that your team members are skilled and function will with all other team members. This is vital to the future of your Scrum Team’s performance.
We have found that organizations, who continue to show exceptional results from their Scrum Teams, have allowed their Scrum Teams to self-select and self-organize. This means that after selecting a product to develop, the organization finds a pivotal team member, who is an expert in the product domain, and they invite them to be the Product Owner. After selecting a Product Owner, the organization usually selects a ScrumMaster to act as a servant-leader for the Scrum Team. Next the team is self-formed in one of many different ways.
One way to allow a Scrum Team to self-form, with the parameters described above, is to assemble all potential team members in a room. Describe, to the group, that the organization has decided to create a new Scrum Team to develop the product. Introduce the Product Owner and the ScrumMaster. Allow the Product Owner and ScrumMaster to present the concept for the new product, and how Scrum Teams operate (if Scrum is new to the group. If not, this can be skipped). Ask the group in the room if they are interested in participating. Thank those that are not interested, and invite them to leave. It may be nice to invite them to stay, in the event they might learn more and help identify other people in the organization that may be interested in joining.
Ask the resulting group to discuss the technical and non-technical details that would be involved in developing the product. Ask them to discuss the inherent, obvious, and hidden risks in developing the product. Ask them to identify the skills that will be needed to make demonstrable progress daily.
Now, have the group decide who, among the group, should be on the team. These decisions should be based on the ability to fulfill all of the identified needs of this product’s development, and the ability of the people in the group who can not only provide this expertise, but also form a working dynamic with other potential team members. When the group has selected the people for the team, thank the group for their help, and invite them to share this experience with other people in the organization.
Reminder: At every step in this example, please remind the group that Scrum is the assumed/intended development framework. But, for a truly self-organizing and self-formed team to occur, invite the group to discuss whether Scrum should be used.
Note: This is only one, of many, possible ways to start a self-selecting (or self-forming) team. Your success may vary depending on environmental dependencies, hierarchical impositions, and the level of empowerment of your employees – among many other factors.
Powering Up / First Usage of Scrum
Starting up your Scrum may be hazardous to your career if you are not properly equipped and/or prepared. This instruction and troubleshooting service bears no responsibility to the outcomes of you using your new Scrum. Understand that what follows using Scrum, as intended/designed or not, is solely the users’ responsibility.
It is our recommendation that before engaging in Scrum, users should take all safety precautions and don protective gear at all times. Only you can prevent a Scrum disaster.
Powering Up Your Scrum
Scrum is a very powerful framework, thus it demands a commensurate amount of focus and energy when first starting up. Keep in mind, Scrum is designed to remain running at all times after it has been started. We cannot stress enough that the best reason for retiring Scrum is the inevitable evolution to another framework or process model (already defined or not). Should you consider powering down your Scrum indefinitely or temporarily, we highly suggest you consult an experience Scrum professional for their advice.
Most successful Scrum starts begin with an informal Kickoff event. To trigger this event, obtain all of the organizational approvals necessary to start an instance of Scrum with the Scrum Team you have already assembled; select a time when all Team Members and Stakeholders can attend a gathering for several hours (some tend to keep this short, to about 2 hours, others may schedule multiple days for this event).
Kicking off your Scrum experience is simple, but to the uninitiated, it might not seem too simple. The best kickoffs involve team building exercises to warm the group up. Usually someone will come in to communicate the product vision to the team(s) – this could be the Product Owner, but may be someone much higher in Product Management. If the team has never used Scrum before, an initial training session may be needed.
Kickoff activities may include selecting a team name, creating a team phone book (contact information – internal and/or external), creating a Team Working Agreement (see below), discussing coordination of multiple teams, selecting an estimation scale (if needed), and establishing a Definition of Ready and Definition of Done.
Finally, some kickoffs include, or lead into, a large Product Backlog refinement session. Some may call this Release Planning, even if it is not truly a Release Planning session.
Immediately following the Kickoff activities, the team should be ready to start Scrumming, or Sprinting. This is good! If the team pushes back and collectively says they need to get ready for Sprinting, there may be cause for concern. Talk of a Sprint 0 (Sprint Zero) may arise. Where some advisors, or Thought Leaders, may chose a ‘side’ on Sprint Zero, we will not. Be warned, though. The topic of Sprint Zero has spawned many a heated debate online, and in person at public Scrum conferences. Engaging in these debates may not get you any closer to solving your team’s kickoff problems.
Start using Scrum on your previously decided start day, at the beginning of the day. The recommended first action is to hold the Sprint Planning event. Get the entire Scrum Team, and anyone else needed, together to discuss what the team will work on during the Sprint. Typically, the Product Owner suggests a Sprint Goal, calls attention to several Product Backlog Items that support this goal, and the team decides how much of the proposed work they can reasonably get done in the Sprint. While teams are still new to Scrum, this generally takes about one hour per week of Sprint. This is widely known as Sprint Planning Part 1.
The team will usually take a break after Sprint Planning Part 1, and reassemble (sometimes without the Product Owner and ScrumMaster) for Part 2. The team then discusses and decides HOW to complete the work they decided to take on. If the team realizes, at any point during Part 2, that they may not be able to complete all of the work during the Sprint, they should get the Product Owner and ScrumMaster together with the team again, to discuss what they believe can be completed.
When the team has decided WHAT to deliver, and HOW to build it, they need to create the Sprint Backlog out of items that represent the HOW part. For instance: My Product Backlog had an item called “Create Scrum Instructions Page”. When I broke that down into achievable pieces, I decided to deliver it in parts called “Inventory”, “Assembly”, “First Sprint”, “Continuing Scrum”, “Scrum Training”, and “Team Working Agreements”. As I worked out HOW to deliver these parts, I identified better section titles, the need for several images, how to create those images, mapped out what would go in each section, and finally started to define in what order I would deliver them. All of those little notes were the Sprint Backlog. As I finished each one, I should have checked to see if I’d accomplished my Sprint Goal (which I didn’t do – doh!). Once I finished ALL of them, and my Sprint Goal was complete, I reflected on the experience.
The Daily Scrum
Every workday, at the same time, in the same location, the team holds the Daily Scrum. What’s really important about the Daily Scrum, is that every Team Member updates everyone else on what they’ve done to get the team closer to the Sprint Goal, talks about any trouble they’ve experienced, and decides what to do next.
To accomplish this fairly simple task, many teams have installed basic questions that everyone must answer. In doing so, teams have probably unwittingly reduced the complexity of this event to the Simple domain, and declared there to be a one best way to get this done. In reality, this is a complex communication and planning tool (the event is) that should be left up to the team to evolve or change as necessary.
Continued Scrum Usage
Three Pillars of Empirical Process Control
Focusing on Retrospectives
Evolving in and out of Scrum
Scrum Training & Certification
Scrum Study, among ALL of the most prolific creators and contributors to the global Scrum community, is not considered a reputable source of Scrum instruction or certification. This accreditation body’s self-injection into the global Scrum community is not supported by any other training or certification body. Please refrain from seeking their services, training offerings, and certifications.
Definition of Ready
Team Working Agreements
Scaling is not available with this version of our product. We welcome you to upgrade to a more expensive and comprehensive version of our product that includes Scaling. Many versions of Scaling are currently available, but we believe that you will be most satisfied with our version. Please contact your friendly Scrum sales associate for more details.