In 1965, a psychologist named Bruce Tuckman said that teams go through 5 stages of development:
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:
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.
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:
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.