SM / PO Cheatsheet: Simple guide to the difference between a Scrum Master and a Product Owner

By Edward Scotcher

This is a simple one page aide memoire that can be used to help explain the responsibilities of the role of Product Owner and Scrum Master. It's great to print off and hand out to people when you are explaining what the roles are and what the differences are between them. So next time you need to talk about these roles, you can use this as a basis for a simple discussion or presentation.

Scrum Master's Responsibilities

• Responsible for helping the team deliver work to the Product Owner
• Makes sure the team can meet its commitments by removing any impediments they face, including Managing dependencies, escalating blockers that they cannot remove themselves
• Facilitates process & meetings (eg Reviews, Stand Ups, Planning, Estimation, Scheduling, Prioritization)
• Makes sure the team is fully functional, productive and improving quality
• Shields the team from distractions and interferences (including the Product Owner)
• Enables close co-operation across all roles and functions, removes barriers
• Responsible for reporting progress, including producing standard outward-facing artefacts
• Manages Product Owners expectations of the team
• Responsible for keeping time and quality requirements

Continue reading this article.

How PD works in Agile team

By Dingshan Li

PD (Product designer) is very important role in software development. They will provide detail requirements specification and business workflow, UI workflow. In traditional software development process, PD will prepare the detail requirement design document before develop team start to make software design. This kind of process will work pretty well if the requirements are clear and relatively stable. Also, there are enough PD resources to make the complex documents. But most of time, we cannot figure out the whole requirements clearly at the start stage. And the scope change is often happen. Another factor is that PD always need to work on more than one product and it is very difficult for them to spend much of time to work out a detail design document. So, what can we do to deal with this kind of issues?

Agile provides a methodology or framework for the team to develop software under the situation of changing scope. By focusing on high value requirement, separating the long lifecycle to be several short iterations and guarantee fully-test in each iteration, it can provide high-quality and expected software to the client. In this kind of framework, how PD works in the team? How they collaborate with others

Continue reading this article.

The Product Owner on One Page: Overview of the Product Owner Role

By Roman Pichler

The following diagram summarises the product owner's responsibility together with the role's key activities and artefacts.

Continue reading this article.

The Land that Scrum Forgot

By Robert C. Martin

Scrum is a starting point. In fact, it’s a great starting point. But, as a framework rather than a full-blown methodology, Scrum is deliberately incomplete. Some things—such as the best technical practices to use—are left for individual teams to determine. This allows a team to create the best fit between their project and environment and an assortment of technical practices.

While that selection of practices should belong to the team or organization rather than to a group of methodologists, the benefits of some practices are becoming so compellingly obvious that they warrant consideration by any Scrum team. But, too many Scrum teams become complacent after achieving some early productivity gains with Scrum. And they stop seeking ways to improve. Many fail to try the technical practices necessary for long-term success. In the following article, Robert Martin (perhaps better known as "Uncle Bob") tells us why so many Scrum teams fail to sustain the promise of their early successes.

Continue reading this article.

Heartbeats: The pace of a Scrum Team

By Rafael Nascimento

One of the challenges in the use of Scrum is to predict how much of functionality a team is able to deliver each sprint. Many try, in a vague attempt to create a metric, to assign a story point a certain amount of work to be delivered, rather than looking how a team play their roles and perform their deliveries. For example, a story point is equivalent to a CRUD with 8 fields that accesses a table in the database. This approach does not work, because a team is made up of people with different experiences, perceptions and problems (personal or professional). Individually and collectively, a team always has different emotional and technical characteristics  from other teams. Team members never take the same time that members of Team B took to adapt to each other. Teams will never manage exactly the same conflict situations or have the same productivity. Finally, in sets filled by human beings, there may even be a statistical  standard for productivity, but never an industry standard, accurate and predictable. There will always be a margin of error. Then comes a question for reflection: is it better to draft a plan and make your team follow this plan at any cost, in favor of a contract or corporate goal? Or would it be better to identify a target and track the performance and growth of your team, guiding it toward its mission, enjoying a harmonious, happy and highly productive environment, and make necessary adjustments to the project plan for the sake of your customers’ satisfaction, offering them transparency, with no surprises?

Continue reading this article.

Ouija Board Estimation

During a recent training course I ran, one of the delegates made a joke about the nature of agile estimation in Scrum teams resembling a "séance"; whereby the team gathers around the table and stares at a number of user story cards expecting something unnatural to happen. How true!  This gave me an idea for a different type of iterative estimation that I tried in practice with ‘Team Woodstock’.  I sat the team around a table and wrote the Fibonacci sequence’s numbers “1,2,3,5,8,13” and a “?” on post-its around the table in the design of a Ouija board.  Once everyone was sitting comfortably, had cleared their minds and entered a trance-like state the product owner read out the story and the team clarified the acceptance criteria.  Then the story was placed in the middle of the table and each team member put one finger on the story – in silence. Without discussion or argument the story started to move towards the number which reflected its size, by the act of the team members pushing or pulling the story towards their chosen number.

Continue reading this article.

Agile Tools vs. Agile Books: The value of tools over the value of books in the agile world

By Paul Heidema

I have been working with Agile for a couple of years. At Berteig Consulting we are using Agile to run our small business. As such we try to use various tools to make our life easier. We have used CardMeeting for our cycles and tasks. I have tried using PlanningPoker for online estimation. It seems useful, but maybe our team is too small to make great use of it. I am also looking for other ways to manage the reflections and learning from each cycle.

I have received an email from David Wolrich of CardMeeting that states: “Anyways, I rely on the trickle of news from legitimate organizations like yours to let users know that CardMeeting is still around, that I am still adding features, and to generate interest; thanks again.” So maybe some of you could try it and give him a shout. Much like other free applications on the net such as Drupal and Neo Office this one could become more robust and useful.

Continue reading this article.