The three clearly defined roles in Scrum:

1. the "Product Owner", who represents the stakeholders and the business
2. the "Scrum Master", a facilitator and project manager, acts as an advocate for the Scrum process.
3. the "Team", a cross-functional group of around 7 people

These three roles are always needed and should people in these roles should be committed to the Scrum process and the project.

Product Owner

In Scrum, a single individual needs to have have final authority with regards to prioritisation of the backlog, customer interests and user requirements questions. This authority and responsibility falls to the Product Owner. The Product Owner represents the voice of the customers/users and works to ensure that the Scrum Team is working on the "right items" from a business perspective.

The Product Owner is responsible for writing customer-centric backlog items also called stories. Each backlog item or story represents a feature or unit of work that is small enough to be completed by the team in a single sprint. While there are multiple inputs to the product backlog, it is the sole responsibility of the product owner to prioritise the product backlog.

Responsibilities of the Product Owner

• Defines and adjusts the features of the product
• Writes user stories and places them in the product backlog
• Prioritises items in the Product Backlog according to customer/market value
• Accepts or rejects work results
• Decides on release date and content
• The Product Owner cannot also be the Scrum Master, however the Product Owner may sometimes be a member of the Scrum Team

Challenges of being the Product Owner

• Be willing to make hard choices during the sprint planning meeting.
• Resist temptation to add more important work after a Sprint is already in progress.
• Balance the interests of competing stakeholders.
• Resist the temptation to "manage" the team, even if team members request intervention with issues that the team should sort out itself.

The Product Owner role needs to have a solid knowledge of the product both from business and user perspective. Typically this is the Product Manager or Product Development Manager however this varies from organisation to organisation and sometimes the Product Owner responsibility may fall to different people from project to project. This person acting as the Product Owner must be available to the team at any time, but especially during the sprint planning meeting and the sprint review meeting.

Scrum Master

The Scrum Master is a facilitator, a project manager and an advocate for the Scrum process. The Scrum Master is not the leader of the team, as the team is self-organising. The Scrum Master is responsible for making sure the Scrum team live by the values and practices of Scrum, enforcing the rules of the Scrum Process. The Scrum Master protects the team from external interferences and by making sure they do not over-commit themselves to what they can achieve during a sprint. The Scrum Master is also responsible for removing any impediments or obstacles faced by the team.

• The Scrum Master is a member of the Scrum Team
• The Scrum Master cannot be the Product Owner

Responsibilities of the Scrum Master

• Removes impediments (obstacles) and makes sure that the team is fully functional and
  productive
• Ensures that the Scrum process is followed
• Updates burndown chart and maintains the Scrum board
• Facilitates Sprint Planning, Daily Scrum and Retrospective meetings
• Maintains the Sprint backlog
• Supports the Product Owner; including communicating updates and impediments as well as assisting with backlog and release plan maintenance
• Ensures that the team’s progress, status and success is highly visible to all stakeholders, including the team itself
• Facilitate creativity and empowerment for the development team
• Shields the team from external interferences

Cross-Functional Scrum Team

The Scrum team are the people who do the actual analysis, design, implementation and testing required to complete the features, stories or tasks in a given sprint. The Scrum team is self-organising, there is no command and control. Everyone in the Scrum team is equally responsible for determining the most suitable way to proceed.

• Agrees on the sprint goal with the product
  owner and specifies in detail the work needed to accomplish this goal
• Demonstrates the work results to the Product Owner
• Scrum team has the authority to do whatever is needed to meet its commitments.
• Self-organising; Organizes itself and its work
• Cross-functional; team members have all the required skills and expertise to complete the tasks given to the team

Ideal Team Size for Scrum

The team should ideally consist of 7 plus or minus 2 people (5-9) with the necessary skills to complete the tasks. Larger teams should either organise in sub-groups or split into multiple Scrum Teams to ensure the team is still effective. Studies have shown that teams exceeding 9 are typically less effective than smaller teams. In smaller organisations the team may be smaller. Currently I’m in a team of three with myself as Scrum Master and Lead Designer as well as a Web Mechanic and a Lead Programmer and plans for on hiring two additional programmers.

A Scrum Team should be Cross-Functional

This basically means that the team should consist of people with the range of skill sets required for the tasks/projects they will be working on. In an ideal scenario the team should be able to function as a self-contained unit and complete all tasks committed to in a sprint without having to rely on external resources or people on a regular basis. If a story or feature requires content or media from other departments or stakeholders then this should be facilitated either by the Scrum Master or by the Product Owner so that the team does not have to chase down this from external sources.

Scrum Team Composition

Some thought should be put into team composition and structure to ensure that the range of skills are sufficient for the tasks at hand. For example a Web Development Scrum Team of 5-8 might consist of:

• a system architect or lead programmer,
• 2-3 programmers,
• a database programmer,
• a Web Designer and/or UI-Designer,
• a front-end developer,
• and a Tester

It is usually a good idea to start small and expand the team once you get a better idea of the split between the different types of tasks you’ll be working on and you’re able to identify any bottlenecks. You might realise that the tasks in the product backlog and the foreseeable future are design heavy and decide to expand the team with an extra designer, or that most of the work will be coding and hire more programmers. Perhaps the team is better served by hiring a dedicated tester to free up some time from all the members of the team.

Additional Roles in the Scrum Process

In addition to the three core roles in Scrum there are also several additional roles that may be involved and have a stake in the project. The other roles may vary from from organisation to organisation and even from sprint to sprint and are not strictly needed for the Scrum Process.

1. "Stakeholders"‘
2. "Managers"

The needs, desires, ideas and influences of these supplemental roles should be taken into account, but should not in any way be allowed to affect, distort or get in the way of the actual Scrum project.

Stakeholders

Stakeholders are typically customers, vendors basically someone with a significant interest or stake in the project. These are the people that the project is being built for, or at least representatives of the wider user/customer base who will be using the software/application/website.

Managers

Managers or Executives are people who will set up the environment for the product development organisations. Managers typically have the deciding vote in whether or not additional full-time resources will be added to the team. Managers may also be involved when it comes to approving costs for additional equipment, training or additional external or internal resources. Managers also have the responsibility to ensure that business goals for the product are clearly communicated to the Product Owner.

Summary

The roles in Scrum fall into two distinct categories. People that are committed and people that are involved. The three core roles, Product Owner, Scrum Master and Scrum Team are all committed (or at least they should be). The committed people have their proverbial bacon on the line, whilst the people that are involved have an interest in the project but aren’t directly held accountable if the project fails. In my experience Scrum needs all core roles to be committed to the process in order to work effectively. A key component of Scrum is to strive to continuously improve. If you’re just starting out with Scum or if you’re establishing a new team it’s never going to be perfect from day one, but if everybody is committed to the process it will improve.

Basic requirements for Iterative development using Scrum

Just to quickly recap from the Introduction to Scrum article these are some of the key requirements for iterative development when using Scrum:

• Iterations must have fixed time boxes and be less than 6 weeks long
• Code at the end of the iteration must be tested by QA and be working properly
• A Scrum team must have a product owner and know who that person is
• A Scrum team must have a Product Backlog with estimates created by the team
• The team must have a Burndown Chart and know their velocity
• There must be no one outside a team interfering with the team during a sprint

Scrum’s Roles, Artifacts and Rituals

Scrum consists of several key elements that make it a solid framework for development and project management. These elements can be broken down into three roles, three artifacts and three ceremonies or rituals.

• Scrum’s 3 Roles
  • Product Owner
  • Scrum Master
  • Scrum Team
• Scrum’s 3 Artifacts
  • Product Backlog
  • Sprint Backlog
  • Burndown
• Scrum’s 3 Rituals / Ceremonies
  • Sprint Planning
  • Daily Scrum (daily stand-up)
  • Sprint Review (Demo & retrospective)

Three core roles in Scrum

There are 3 core roles in Scrum, people in these roles should be committed to the project and the Scrum process.

• Product Owner: Represents the stakeholders and the business, prioritises items in the backlog
• Scrum Master: Facilitator and project manager. Acts as an advocate for the process
• Scrum Team: Cross functional team of 5-9 people. Self-organising, does the work and implementation.

In addition there are supplemental roles referred to as "Stakeholders" and "Managers". These people typically have a vested interest in the project or development but aren’t committed to the process and typically aren’t held accountable for any failures or delays. The opinions and input of these people needs to be taken into account but they should not be allowed to directly interfere with the team.

I’ll go into much more detail on the Roles in Scrum in my next article.

Three primary artifacts in Scrum

• Product Backlog
• Sprint Backlog
• Burndown

Product Backlog

The product backlog is at the heart of Scrum. The product backlog is essentially a prioritised list of requirements, features, improvements, fixes and so on. Items in the backlog are things that the customer(s) or users want, or things that in some way enhance the product. These items are typically called stories, or sometimes just backlog items. Stories should be written in the language of the customer/user detailing a unit of work that can be completed by the team in a single sprint. The product backlog may have multiple inputs but should be prioritised by a single person, the Product Owner.

• The Product Backlog should contain items that will be worked in the next 12 months
  • Stories that are very unlikely to be developed in the next year then they should not be included in the Product Backlog
  • This helps avoid cluttering the backlog with items that are very far in the future or may never be developed at all and keeps focus on more immediate targets
• The Product Backlog should ideally contain no more than 150-200 backlog items
• Items in the Product Backlog should be in prioritised order as prioritised by the Product Owner
  • Priorities can and will change as conditions change and new information becomes available
  • It is not vital that everything is prioritised in exact order, the lower an item is on the priority list the more vague the priority tends to become
  • When prioritising items that are lower on the list it’s usually good practice to consider the backlog item in relation to other backlog items of similar priority (e.g. is feature A more or less important than feature B)
• The higher priority and the closer a backlog item is to being added to the sprint backlog the more detail it should have
• Items that are further away from being worked on will typically have less detail, however more detail should be added before an item is scheduled for a sprint
• Larger stories are typically called Epics and should be broken down into smaller stories before they are added to the Sprint Backlog

The Product Owner may also request rough time estimates for backlog items to assist in prioritisation and calculating business value of backlog items.

Sprint Backlog

The Sprint Backlog is a prioritised list of Stories or Backlog items that will be completed in the next Sprint (development cycle/iteration). Stories that are added to the Sprint Backlog should contain enough information for the team to complete the story.

• Stories in the Sprint Backlog should be prioritised by the Product Owner
• Stories in the Sprint Backlog should all have time estimates
• The Product Owner and the Team agree on the contents of the sprint based on the available sprint time and previous velocity
  • The team should take into account all known factors for the upcoming sprint period e.g. planned holidays for team members, conferences, public holidays, recurring business as usual tasks etc.
  • The Product Owner may re-prioritise some stories based on size and available time to "fill up" the sprint
• Some teams also set aside a percentage of available sprint time for fixing bugs, reducing technical debt and/or refactoring
• Prior to the start of the sprint all stories should have estimates, be clearly prioritised and be broken down into tasks
  • Task breakdown is done by the Team during the planning phase
  • The Product Owner should not interfere with task breakdown or estimates

Burndown

The burndown chart is a visual representation of the Scrum Team’s progress in a given sprint. It is updated by the Scrum Master every day and allows the whole team and any involved stakeholders to get a quick visual overview of the progress of a sprint.

• Daily progress for a Sprint over the sprint’s length.
• Graphical representation of work left to do versus time.
• Outstanding work is represented on the vertical axis, with time along the horizontal.
• Updated daily by the Scrum Master
• Useful tool for gauging whether tasks will be completed within the sprint or not

Three central rituals or ceremonies in Scrum

• Sprint Planning (Task Breakdown and Estimation)
• Daily Scrum (Daily stand-up)
• Sprint Review (Demo & Retrospective)

Sprint Planning – Task Breakdown and Estimation

In Scrum the "big design up-front" approach is discarded in favour of a smaller units of work where the choice of implementation and solution is often left much in the hands of the team. So instead of providing full, detailed descriptions of how everything in the project is to be done, a lot of this is left up to the team. This is done because the team will know best how to solve its problem. The product owner provides the team with desired outcomes from a user and business perspective rather than suggested technical solutions which is typically not the area of expertise for the product owner.

• Sprint Planning isn’t a roadmap or a strategy discussion.
• Time-boxed to 4-8 hours which is typically sufficient for a 4 week sprint
• The overall theme or focus of the Sprint, and majority of the product backlog scheduled for the sprint should be prepared and and published prior to the meeting
  • This is the responsibility of the product owner or the Scrum Master
• The team should have at least a day to review the items in the Product Backlog that are scheduled for the sprint
  • The team needs enough time and information to understand what implementing each backlog item would require
  • The time reviewing the preliminary sprint backlog should also be used to add technical-driven features for consideration that may be required to support planned features

During the Sprint Planning the team will initially estimate the relative size of each story, typically during a process called planning poker. This process minimises the risk of vocal individuals influencing the estimate and reduces underestimating of tasks. The planning game starts with the Scrum Master or one of the developers with the most knowledge regarding a specific feature providing the team with an overview of the feature and work required. Each team member then places a card with their estimate face down on the table and everybody reveals their estimate at the same time. The highest and lowest estimate then discusses their reasoning then everybody votes again until a consensus is reached.

• Stories are estimated in relative size using "days" or "story points"
• Estimating in relative sizes has been show to be a lot more accurate than trying to use actual or specific units of time
• Tasks are estimated in hours

During sprint planning each story is broken down into multiple tasks. Tasks should consist of all the individual bits of work that will be required to complete the story. During the task breakdown the team typically discusses technical and implementation solutions but may defer final choice of implementation to be decided during the sprint. One of the tasks for that story might then include researching, spiking and choosing an implementation for the story. While the stories are estimated in days or story points, tasks are estimated in hours. The planning game can also be applied to task estimation.

Daily Scrum

The daily stand-up meeting or daily scrum is one of the core rituals or ceremonies in Scrum. This daily meeting gives the team and Scrum Master a daily update on progress, enabling obstacles and potential problems to be identified and dealt with as early as possible before they become real problems. It also enables the Scrum Master to make adjustments to the sprint plan to ensure things are kept on track. This could be reducing the scope of tasks or agreeing with the Product Owner to defer or drop certain stories to ensure that stories with higher priority are completed.

• Same time every day. Keep the meeting at the same time every day. All team members need to attend.
• Everybody stands. Making everybody stand keeps the meeting short and to the point. Any longer conversations should be deferred to after the meeting.
• No longer than 15mins (timed)
• The daily Scrum typically has the following format:
  • Done: Each team member states what they have done or achieved in the preceding 24 hours
  • Obstacles: Each team member states whether they have any impediments or obstacles preventing them from working effectively on sprint tasks
  • To Do: Each team member states what they plan to work on in the next 24 hours

Prior to Scrum all team members should update remaining estimates for tasks. The Scrum Master should then update the burn-down chart so that the entire team gets a clear and visual representation of their progress.

Sprint Review – Demo and Sprint Retrospective

The Sprint Demo

At the end of each sprint the team demonstrates the work completed in the Sprint to the Product Owner and potentially some stakeholders. The demo to the product owner should showcase the completion of each story committed to during the sprint. The demo should make it clear what aspects of the stories are not complete, if any, and what the plan is for getting them completed.

• During the demo it should be made clear which features are unimplemented due to being scheduled for a future sprint.
• This will help avoid questions/concerns from the product owner about those features being missing or ugly.
• If the sprint was done correctly, there should not be any surprises at the demo.
• Acceptance testing should have occurred during the sprint giving the product owner previews of the features to avoid any major changes or unexpected rejection of implementations

Inevitably there will be some minor tweaks suggested by the product owner and/or stakeholder during the demo. The team should only accept tweaks that can be completed during the slack period unless the product owner is willing to sacrifice either delivery date or other release features. Any bugs discovered prior to, during or after the demo should be fixed during the slack period prior to release rather than deferred for later or added to technical debt.

The Sprint Retrospective

After each Sprint the team holds a Sprint Retrospective meeting. The meeting acts as a self-assessment for the team and aims to improve processes for future sprints. The sprint retrospective should never be used to place blame but should be an objective review of what went well and what did not go so well during a sprint that can be improved. To be a successful and agile team you need to continually improve your work habits and update your process to match changing situations. Retrospectives are a great tool for achieving this.

• Duration: 1-3 hours depending on size of team, duration of sprint and expected discussion
• Location: Room or area with where you can have an undisturbed discussion. Preferably somewhere with wall/whiteboard
• Participants: ALL team members, the Scrum Master and optionally the Product Owner
• Should never be used to place blame
• Review the previous sprint and consider the following questions:
  • What did we do well, that if we don’t discuss we might forget?
  • What did we learn?
  • What should we do differently next time?
  • What still puzzles us?
• Identify a single area of improvement to focus on for the next sprint

Summary

Well that’s it, perhaps not the shortest or most concise explanation but it should give you the building blocks to work with and consider whether Scrum is right for your organisation.

Perhaps the most common mistake people make when attempting to use Agile or Scrum is that they don’t commit to the process enough but rather just pick and choose elements that fit with their organisation or previous methodologies. This may work in some instances however more times than not it’ll generate rather poor results and generate a rather poor impression of Agile within the company. To be successful you and your organisation will need to devote both time and resources to learning and implementing Agile well. It’s recommended that you start out following the standard principles of Scrum and avoid large deviations until your team has a few sprints under its belt and are familiar with the principles of both Agile and Scrum. It’s always better to know the rules before you start bending or breaking them.

Scrum and Agile Development Books

• Scrum & XP from the Trenches
• The Art of Agile Development
• Succeeding with Agile: Software Development Using Scrum
• User Stories Applied: For Agile Software Development
• Agile Estimation and Planning
• Agile Testing: A Practical Guide for Testers and Agile Teams

What is Scrum and Agile development?

Agile development is uses an iterative process, rather than the waterfal method, and focuses on shorter release cyles with constantly evolving requirements through collaboration between cross-functional teams. Agile allows development to be adaptive (or agile) to respond to changing market conditions or internal or client requirements.

Scrum is a lightweight agile development process framework for managing projects. It is widely adopted within software and web development but the principles can be applied to virtually any type of project . It includes a set of practices, predefined roles and artifacts based on an iterative agile process cycle. Scrum is not a definitive set of rules for how to do thing but more of a holistic approach to development with a set of guidelines and principles rather than a strict development methodology. In a way you can think of Scrum as a sort of framework for project management but it’s much more than that..

Basic requirements for Agile iterative development:

• Iterations must have fixed time boxes and be less than 6 weeks long
• Code at the end of the iteration must be tested by QA and be working properly

The Nokia standards for Scrum:

• A Scrum team must have a product owner and know who that person is
• A Scrum team must have a Product Backlog with estimates created by the team
• The team must have a Burndown Chart and know their velocity
• There must be no one outside a team interfering with the team during a sprint

There are many ways you could implement Scrum and successful formulas will vary from organisation to organisation. To effectively use Scrum and Agile you should embrace the princples and adapt the process to fit your team and your organisation. Part of the principles of Agile is to constantly evolve and that includes internal processes as well. After each sprint or cycle the team reviews what went well and what did not go so well and commits to improving at least one achiveable thing during the next cycle. Over time the team becomes both more productive and generally happier as there is less friction and they are able to deliver more.

• To do Scrum well you need to adapt it to suit your own organisation, team and project or product you are working on
• To do Scrum well you will need to continously evaluate and improve on your processes

Even though Scrum was originally intended for managing software development projects it can be applied to any number and types of project as a general apporach to project management.

Basic principles of Agile and Scrum

• Agile avoids "Big design up front" allowing for decisions to be made at the last responsible moment
• Agile uses iterative cycles with shorter bursts of development known as "Sprints"
• Agile emphasises real-time communication over written documents, preferably face-to-face.
• Agile teams tend to sit together and include all the people needed to complete the project/product/software (cross-functional teams)
• Agile focuses on delivering smaller working features or system components as the primary measure of progress
• Agile aims to release early and release often
• Agile tends to produce significantly less written documentation, instead focuses on self-documenting and easy to use systems.

Why use Agile?

Market conditions and requirements change very quickly especially in an online environment and the digital world in general. It is typically very difficult to foresee all the vital requirements and obstacles at the beginning of a project. Client and/or internal requirements will inevitably evolve over time and move further and further away from the initial specification so even if you deliver the project to the exact specifications given it will not succeed or meet customer, client or market expectations. When using Waterfall or similar methodologies the core requirements will have changed even before the planning and documentation phases are complete and shift even more during the duration of the project. Agile allows you to make decisions at the last responsible moment and continuously adjust the direction of the project to ensure you meet changing requirements.

Scrum explained in less than 10 minutes

For a quick introduction to the Scrum process check out this video by Hamid Shojaee (Axosoft.com). It’s short, concise and quite entertaining. Not everything is explained in detail but it is a good introduction and covers a lot of ground in just a few minutes.

Agile Values and Principles

Manifesto for Agile Development – Values

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thom

Principles behind the Agile Manifesto

We follow these principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Summary

I’ve been working with Agile and Scrum development for almost 5 years now. During that time I’ve had the privilege of experiencing Scrum from the perspective of all the core roles initially as a Product Owner, the primary designer in Scrum Team and most recently Lead Designer and Scrum Master in a Web Development Team. While there’s been some challenges along the way I couldn’t imagine going back to using a different development process. Whether you’re looking to change development methods, are fed up with Waterfall or you’re just getting started I recommend you look into Agile and Scrum.

Do you have any experiences with Agile Development? Share your war stories in the comments below.