Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


On the recent release of Scrum Guide 2020 and changes to Scrum methodology

Well, a little over a week ago, Schwaber and Sutherland released the Scrum Guide 2020  and it introduced some changes and new concepts, including

  • Reduced prescriptive guidance
  • One Team One Product
  • Introduction of Product Goals and Sprint Goals
  • Self Managing over Self Organizing
  • "Why" added to sprint planning topics of "What" and "How"
  • Language simplification

I'm interested in people's thoughts on these changes, both within the orthodox Scrum methodology, as well as how its applied by Atlassian.  The following was captured from discussions with stakeholders in my organization regarding my initial assessments, so its just opinion.  I am a senior architect and strategy leader at an international financial organization, and I've been a scrum master for 17 years.

In respect to Product Goals, I agree with the principle, but both Schwaber and Sutherland, while having the goal of 'enabling business agility at scale across an entire organization', simply don't deliver, and instead provide a product-centric lens through which to view this agility, which I believe both devalues what can be offered, and is misleading to those who just blindly follow dogma. On the one hand, I'm happy to see, after 25 years, for them to come to realize that alignment with greater goals and getting to the 'why' is important, and yes, its a move forward, but I would argue that they've still missed the mark. While I can get behind 'The product owner is responsible for making sure that the Product Backlog has a goal that the team understands, is excited about it and commits to it — and the whole team are moving together towards it.', this is team alignment with the product owner's goal, with nothing about clarity and alignment around higher level goals and who that product owner in turn delivers to. It also implies that a product goal is static and can be completed. And I appreciate the problem they have, in that Scrum is to some extent a bottom-up self-actualizing model with the only top-down in the model coming from the product owner, so top-down alignment is already a challenge.

It doesn't give people 'below' the product owner the big picture of what they are aligning to and why. But on the other hand, a *good* product owner should be able to encapsulate and express this in the scope of the team and their domain of work, so a Product Goal can do this. One of the big downfalls of Scrum that I've encountered over the years has been that certain personalities are task-oriented, and simply want to complete an item, which ends up causing problems if there isn't a complete and accurate set of tasks defined to fulfill a goal.  This approach of adding a Product Goal at least shifts the thinking to focus on what outcome is desired instead of on the list of tasks to be completed, and I like that. The practical downsides though are (a) you need a good product owner who can define a goal well, and that could be challenging, (b), this guide proposes that the goal belongs in the Backlog as a grouping mechanism, which is good in theory, but when you have tools like Jira for scrum management, then it will be a bit puzzling how to realize this. As well, this is complicated by the program management needs across multiple teams within the same product line (the basic premise is One Team One Product, but that isn't realistic for many large enterprises, and is even more questionable when teams are in fact microservice focused).  I think it could be implemented, but you might end up violating SAFe portfolio/program management principles to make Scrum work; whoever sets the Program Epic at the program level could effectively define a common goal for all teams working on the Program Epic, but then no team could effectively achieve the goal on their own. So instead move the goal back down to the team and scope it to the team. Teams lose sight of the overall goal with only a few people focused on the actual goal above the team level, but this may still be of value for alignment.

Pragmatically I'm puzzled about how to implement; Perhaps using tags in Jira to group backlog into goals could work, but clear visibility and reminders of the goal would be missing. I'm curious how Atlassian will address this, as they too must respect both Scrum (Jira) and SAFe (Advanced Roadmaps and Jira Align), my guess is that they'll implement purely in Jira, not add a new level to backlogs for goals (basic architectural problem with using Jira are the hierarchy limits), but might implement some way to have a new goal element (perhaps based on tags) with UI integration at the backlog and backlog item levels. This of course doesn't solve how to implement Sprint Goals, but that might be done through the Sprint Definition mechanism, and I suspect might actually be easier (Schwaber and Sutherland specifically call out that the product goal belongs in the backlog, and that the rest of the backlog relates to that, defining what will fulfill the product goal). 

I also note that Definition of Done does not touch on the either the Product or Sprint Goal, yet the Product Goal is the long term objective, and the Sprint Goal is the goal of the sprint.  In a worst case, it seems teams might be put back in the position of not knowing when they've successfully completed a sprint.

So, I think its an improvement, but is not a cure-all, and the goal of enabling business agility at scale across an entire organization remains elusive, especially for medium-large organizations.  It is incredibly important that information flow freely, and that alignment with enterprise goals is maintained, especially in fast growth and large organizations, so being able to provide the "whys" of things is more critical than ever these days.  So these changes help, but they change very little about how i solve the fundamental problems of communication and alignment.  That position will be different for everyone and be related to the size and maturity of their organization, so I know this change will work for some, perhaps many.  What do you think of the new changes? 

1 comment


Log in or Sign up to comment
Kat Warner
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
Nov 24, 2020

There are some interesting wording changes:

  • I like that "development team" has gone allowing for a more unified feeling to the scrum team
  • It will be interesting to see the impact of the word "accountabilities" rather than roles will make to the job titles/descriptions of those who are scrum masters and product owners. Will we see more people who have to balance the accountabilities of being a developer alongside the accountabilities of scrum master/product owner?

I'm interested to see the discussions that arise out of the changes.

Me too Kat!  I'm actually good with the idea of balancing these mixed accountabilities (for those with mixed roles of course), in that the accountabilities should have been there all along, but sometimes people are able to avoid this through process.  To me, its similar to the concepts of dealing with design, user and process documentation, even QA, etc within scrum.  Some embrace these simply as parts of the definition of done and are part of the same sprint where a backlog item is fulfilled.  Some recognize these as individual backlog items, but not necessarily in the same sprint, and of course their definition of done changes.  Some though use the methodology somewhat as an excuse to skip these tasks altogether, and its the latter model that I'm thinking of in respect to accountability.  If (and I'm not proposing this) formalizing design and documentation was in the guide, then teams inclined to ignore this would have a harder time doing so.  Perhaps spelling out both that teams should understand the 'whys' and be accountable, and for goals instead of tasks/backlog items is a bit of that formalism to improve these kinds of team anti-patterns.  Pure conjecture on my part though.

AUG Leaders

Atlassian Community Events