Professional Scrum Training Courses
Professional Scrum Competencies
Scrum.org has created these Professional Scrum™ Competencies to help guide an individual’s personal development as they learn Scrum.
New and Now at Scrum.org
Professional Scrum Product Owner - Advanced Training Course
Advanced Scrum Master course designed to support experienced Scrum Masters in their professional journeys.
Updated Professional Scrum Product Owner Certification Assessment Levels
Comprehensive series of Professional Scrum Product Owner (PSPO) certification assessments with fundamental, advanced and distinguished levels.
Mastering Professional Scrum
A Practitioner s Guide to Overcoming Challenges and Maximizing the Benefits of Agility
Agile Leadership Toolkit Book
Learning to Thrive with Self-Managing Teams
Professional Scrum Certification Assessments
New Blog Posts
Michel van der Meulen
Are you a Business Analyst and do you currently fulfil the role of the Product Owner? Or otherwise the Product Owner may have delegated some tasks to you, for lack of time to deal with those themselves. How well does that work for you? Can you manage it? Do you know the difference between these two roles and what additional tasks and responsibilities you have been given when adopting the role of the Product Owner? As a Business Analyst with an analysis background you already have many skills that are important to fulfil the Product Owner role. You know how to elicit requirements, to ask the right questions, to write user stories and to refine requirements. When stakeholders think too much in terms of solutions, you will inquire after the underlying requirements. Great, that is a good start for performing the role of the Product Owner. More responsibilities However, as a Product Owner, more is expected from you, because you have a different position within the organization and your responsibility goes beyond that of a Business Analyst. The Scrum Guide says: "The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team." But, what does maximizing the value actually mean? As the Product Owner you are expected to deliver a (software) product that enhances the business potential and is valuable for the organization and its stakeholders. The Return On Investment (ROI) and Total Cost of Ownership (TCO) must be positive over the entire product life cycle and the Product Owner manages this during the entire development process. For that reason it often happens that the break-even point is already accomplished during the development period. That is quite a challenge and not an easy task at all! That is why the Product Owner should be someone from within the business, because the business itself knows best how to balance investments and revenues. In fact, one might say that the Product Owner is in fact a Product Manager. As the Product Owner you can only take your responsibilities if you have adequate authorities and mandates. The Scrum Guide is very clear about that: "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." From Business Analyst to Product Owner Being the Product Owner responsible for expanding or modifying a mature and stable system is quite different from being responsible for developing a new system for a new process, service or product. When you are expanding or modifying a mature and stable system, your main responsibility is managing the Product Backlog and the Product Backlog items. If your approach is Value-Driven and you keep a keen eye on stakeholder management, your success as a Product Owner is guaranteed. New product When developing a new product, you will face increased demands. As the owner of this the new product you are the one who has a vision and you know (or think you know) how business problems can be solved and business goals achieved with your product. It is not just about defining and clarifying requirements and managing the Product Backlog any longer, but it is about managing the Product as a whole, the big picture. It is about Product Management. What direction is the market moving into? What trends must be observed? How do we respond to that? To know that you are still on the right track you need frequent feedback from the business itself, the users and the market. Thus you will be able to quickly detect changes that impact your goals, and be able to respond to them. Frequently delivering an increment of the system will automatically provide you with the feedback you need. This is also the way to create business value while still in the process of developing the product. That is why release management is also a responsibility the Product Owner faces. The path towards the Product Owner role Your knowledge, skills and experiences as a Business Analyst are a solid starting point to fulfilling the role of the Product Owner, because they enable you to perform one of its core tasks: Product Backlog management. As a Business Analyst you have an excellent head start to become a good Product Owner who is able to create more value for the organization, because with the corresponding authorities and mandates within the business you can exert more influence. Two steps towards becoming a Product Owner It is recommended to become the Product Owner of an existing mature and stable product first. In that capacity you will need to present the product in a value-driven way in close collaboration with the Development Team, and it goes without saying that you will need to manage the expectations of the stakeholders. That will probably be quite a handful to start with. From there you can develop in your role as the Product Owner as intended in Scrum: an Agile Product Manager with a vision, an entrepreneurial mentality and responsibility for the product strategy, budget and ROI. Nicole de Swart & Michel van der Meulen www.michelvandermeulen.com Nicole de Swart is the author of the ‘Handboek Requirements’ and with her company Reaco Academy she helps Business Analysts to apply the right combination of agile and traditional requirements techniques. Special thanks to Ron Brouwer (www.c1rcularmovement.com) for assisting with the English translation. Photo by Katka Pavlickova
An introduction of the Brazilian - Portuguese edition of the paper "The 8 Stances of a Scrum Master". The translation and new visualizations are created by Fabio Fioratti Azevedo and Danilo Almeida.
Choosing how you will walk through your day, having fun with your colleagues and clients, actively listen and participating in collaborations, and ensuring others also have a great day. I have written a short story a while ago about the basics of the Fish! Philosophy for being an outstanding team member. In two other blog posts, I covered how this can make your Sprint Retrospective more effective, and also how it can improve your Sprint Planning. Now let’s have a look if this can also work out for your Daily Scrum. What does the Scrum Guide say about the Daily Scrum? “The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.” In short: have the progress transparent, inspect progress towards the Sprint Goal, and adapt the Sprint Backlog to optimize the chances to meet the Sprint Goal. The participants of this session are the Development Team members. The Scrum Master’s sole responsibility is that the Daily Scrum takes place and teaches the Development Team to stay within the 15-minute time-box. The Product Owner can attend, yet should not disrupt the session in any way. The same goes for others who want to attend. Scenario A: It’s 9:00. The Scrum Master is present at the Team Board. Just as agreed weeks ago. 9:03. Still lonely, he goes asking the Development Team members to join him at the Team Board. After about 10 minutes most team members are there. Some are chatting in pairs, some just leaning against a closet. Waiting. The Scrum Master jumps in and asks each team member what they did yesterday, what they plan to do today, and if anything is blocking them. In summary it seems nothing is blocking them and they’ll continue doing what they did yesterday. It feels a little strange as the past three or four Sprint Reviews there were quite a number of items not addressed at all, each time jumping over into the next Sprint. Let’s hope that this time it will be different and indeed nothing is blocking their progress. Scenario B: It’s 8:50 and most of the Development Team members are already in the house. Some are already having conversations around the Team Board, others are checking the logs of the latest built of the system (they are doing daily builds – something we might want to have a conversation about in the next Sprint Retrospective, we’ll see). And two others are coming in with… really, a platter full of steaming well-smelling cups of coffee. On second view, there are also cups of tea. How nice of them. 9:00 sharp one of the Development Team members points to the Sprint Goal on top of the Team Board (for which a team member found a funny metaphor during the Sprint Planning session) and explains that she already checked with another colleague that in pair they would tackle an interface that blocked part of the team yesterday late afternoon. They indicate they are pretty confident they have found a solution which they want to try out. Another colleague jumps in after the Fish was thrown to him. He has finished the development of a Product Backlog item and indicates it is ready for the Code Peer Review. Jake will take it up before starting on another item. Next he would love to collaborate with someone to learn about a testing technique/pattern he read about last week to tackle some of the Product Backlog Items that were ready for “independent” testing – i.e. not by someone who developed on it (and of course did the unit testing). Three volunteers at once. They continue their conversation on what best can be done for the last item in process to get it closer to “Done”. The focus on the Sprint Goal really helped them again to finalize things instead of taking that next item and bring it “in-process”. 9:14 and every Development Team member has a clear view on what each one in the team will do to bring the Increment a number of steps closer to Done and closer to the Sprint Goal. Allow me to assume that you would prefer scenario B. Why is that? It feels straightforward doesn’t it. In fact, in contrast to scenario A, scenario B does implement the four simple practices of the Fish! Philosophy. "Make their day": it can be as simple as a cup of hot chocolate. Or just thinking about that colleague that does not drink coffee but tea. Or volunteering to help someone out on a difficult topic. "Play": the Development Team members facilitated their own session; they took the lead; they are self-organizing. Which in itself is more fun than being commanded by someone who manages a meeting. By throwing the Fish around as a prop to indicate who has the word both makes it clear who is in the lead, and … we all know not everybody has the same throwing or catching skills and there is always some fun with this. "Be There": clearly the team was focused. Focused on the Sprint Goal. But especially to each other. Given they responded very fast to provide help or to collaborate shows that they were actively listening to each other. And all-in-all, this way of having the Daily Scrum was their own choice. They choose to focus, to listen, to bring a coffee for the colleagues, to take it into their own hands, etc. They did apply “Choose Your Attitude”. Anything you want to change about how your team acts during the Daily Scrum events? Let us know, we might help you out. Fish! on…
Guillem Hernandez Sola
Hoy voy a estar examinando una pregunta que es simple. Esta pregunta es compleja en la respuesta. La pregunta es la siguiente: ¿Deben los Scrum Master ganar tanto o más dinero que los desarrolladores de software?