One of the main responsibilities of the Product Owner is managing the product backlog. It’s a team effort to refine the backlog, but the Product Owner is the one responsible for prioritising the backlog. This is a challenging job. Product Owners who are new in their role think the backlog only contains user stories for new features. But they soon find out this is only a part of the backlog. But what are the other parts? And how to find the right balance between them? This is where the ‘backlog prioritisation quadrant’ shows its value.

The backlog prioritisation quadrant is shown in the picture below.

The quadrant divides the backlog in new features, architectural innovation, support and technical debt.

Paper was written by Professional Scrum Trainer Barry Overeem. According to the Scrum Guide, Scrum is a framework within which people can address complex problems, and productively and creatively develop products of the highest possible value. It’s a tool organizations can use to increase their agility.

Within Scrum self-organizing, cross-functional, and highly productive teams do the work: creating valuable releasable product increments. Scrum offers a framework that catalyzes the teams learning through discovery, collaboration and experimentation.

A great Scrum Team consists of a Product Owner who maximizes value, a Scrum Master who enables continuous improvement and a Development Team who focuses on delivering high quality product increments. For sure this sounds great!

But what are the characteristics of such a great Scrum Team?

In first attempt at attaining agility, Intralinks took a well-intentioned "mechanical" implementation of Scrum - done in good faith and with lots of hard work - but failed to deliver against their goal of greater agility.

So, they took on a "Scrum Reboot" and succeeded by augmenting the mechanics of Scrum with the fundamental idea of inspection and adaptation and the Scrum Values of Courage, Focus, Openness, Respect and Commitment.

These provided the cultural environment necessary for success. Look at this Case Study:

In this video Richard Hundhausen, Professional Scrum Trainer talks about software delivery as a team, living the Scrum values, and using Microsoft Visual Studio Team Services (VSTS) to plan and execute the work.

Download NEW Scrum Guide 2020.

If you want to learn more about Scrum and Agile software development then this Agile Masterclass: Scrum for Product Owner and Scrum Master is the perfect thing for you:

If you liked this article, please like DM Spot FB page, Twitter, or LinkedIn and be notified when a new article is published.

Although Scrum has been around for more than 21 years, and is practiced by more than an estimated 18 million people around the world, we are always learning. Over the years, many myths about Scrum have surfaced; some of which may lead your team astray.

In this 1-hour interactive webinar, it is covered:

• Common myths and misconceptions about Scrum
• The Scrum framework according to the Scrum Guide
• How to implement Scrum concepts using Axosoft
• You’ll walk away with a clear understanding of how to achieve your Scrum team’s objectives using leading tools and trusted resources.

Agile and Scrum Masterclass:

Download NEW Scrum Guide 2020.

If you liked this article, please like DM Spot FB page, Twitter, or LinkedIn and be notified when a new article is published.

We'll compare characteristics of Plan Driven and Agile Software Development so that we know where these things came from and what we can expect out of them. What we ultimately came to understand as Plan Driven or Waterfall Software Development originated with the 1979 IEEE paper from Winston Royce "Managing the Development of Large Software Systems.

The idea of Waterfall was that one phase wouldn't begin until the previous was complete. However, if your team moves from coding phase to testing phase then things will have implications back in the development phase (so we found a bug, he'll fix it).

Another very interesting thing the longer the project goes on, the more the design is going to be understood and fleshed out. Therefore, you can never design a system in the beginning and understand it all the way through to its completion. The design of a system will evolve the more we understand the better requirements.

Software development teams are focused on delivering pieces of a product. The last thing most of them want to do is be in meetings. One thing that's going to take them away from doing that is being in a meeting. So what scrum does really well is provide the minimum set of meetings necessary.

All events are timed boxed events that are such that every event has a maximum duration depenting on sprint duration:

This is the Story of the FBI Sentinel Program. You can see how much money the FBI spent to have successful IS. In this video you can also see facts of traditional Waterfall implementation and Agile with Scrum implementation: