In 1965, a psychologist named Bruce Tuckman said that teams go through 5 stages of development:

  1. forming,
  2. storming,
  3. norming,
  4. performing and
  5. adjourning.

The stages start from the time that a group first meets until the project ends. Tuckman didn’t just have a knack for rhyming. (Although, it does make the stages easier to remember.) Each is aptly named and plays a vital part in building a high-functioning team.

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:

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.

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

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:

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.

Welcome

Hello Everyone :)

Thank you for visiting Sci & Tech Portal. It contains articles about Information technologies, Lifestyle...

You will surely find something to read in between the lines too, namely, my love and effort invested into making my communication with you original, useful, and attractive, as well as a promise of continuous improvement.

If you've found the site helpful or useful then please consider throwing a coffee my way to help support my work

Preporuka