Implementing the Product Backlog. A practical overview on how to setup an effective Product Backlog

Ron Eringa Door: Ron Eringa,  10-04-2014
Onderwerp: Product Backlog  
Scrum Guide:
“The Product Backlog lists all features, functions, Requirements, enhancements, and fixes that constitute the changes to be made to the product in future Releases. Product Backlog Items have the attributes of a description, order, estimate, and value.”

One of the most important artifacts in Scrum is the Product Backlog. The Product Backlog is owned by the Product Owner and should be the single source for any changes that you make to your product.

The Scrum Guide tells us WHAT a Scrum Team should do with the Product Backlog to guarantee that we are continuously focusing on building the highest value features each Sprint. What the Scrum Guide doesn’t tell us is HOW to implement this Backlog and how it is used on a day to day basis. This is actually a good thing, since we don’t want to be too prescriptive towards our community, do we?

Validated Value – continuously improve your impact

Peter Koning Door: Peter Koning,  08-04-2014
Onderwerp: Validated value  Retrospectives  

Process like Scrum, Kanban, ITIL and Waterfall all describe the steps from idea until delivery to the customers, or from requirement, bug, wish or problem until potentially releasable to customers. They all describe how to deliver value. Which is good, but not good enough.

The only problem is that the real power of Agile isn’t in increasing the value. The real power of Agile is in maximizing the things not done and maximizing the impact. So how can we maximize our impact continuously? Because many process don’t look beyond the output step, we aren’t focusing on validating the value we’ve delivered, on the impact we have at our customers. How can we learn from the things we’ve created and delivered in such a way that our next delivery to our customers is even better? How can we validate our delivered value?

Analysis Paralysis or: How I learned to stop worrying and love to code

Harm Pauw Door: Harm Pauw,  07-04-2014
Onderwerp: Analysis  Craftsmanship  Backlog Management  

Let’s say your team has a feature on the backlog that it wants to implement. It’s been discussed during a number of refinement meetings, but the team still thinks that needs more analysis before it is ready enough to start implementing it. Otherwise, it might happen that they implement it the wrong way. So you keep on analysing but it takes ages before the feature is finally implemented. It wouldn’t be a problem if this happens once in a while, but if this occurs frequently and it stops you from delivering new features, your team might suffer from something called analysis paralysis.

Management High Five

Peter Koning Door: Peter Koning,  01-04-2014
Onderwerp: Agile Management   Craftsmanship  Motivatie  improvement  

When I was a manager, I was trying to create a culture of continuous improvements and innovation. This often was a hard job. Keeping the balance between business as usual and making time for improvements and innovation is difficult. Over the past months I did an interesting discovery that I would like to share. It took me quite some time before I really understood it. I hope you can understand it much quicker than I did!

Groups & Scrum: How to stop a team?

Stephan van Rooden Door: Stephan van Rooden,  25-03-2014
Onderwerp: Groups  Retrospectives  Scrum Teams  Agile Coaches  

This is the fourth post in a series of blogs on groups and scrum. In the first three posts, I focused primarily on explaining the benefits of groups from a social psychological view. This post will take a more practical point of view.  So based on what I described in the previous posts it shouldn’t come as a surprise that this collection of individuals which we call a team, eventually becomes a real team! Hurray! But what if the team has to stop?

Groups & Scrum: Knowledge Sharing

Stephan van Rooden Door: Stephan van Rooden,  20-03-2014
Onderwerp: Groups  Motivatie  zelfsturende teams  Scrum Teams  

This is the third post in the blog series on groups and Scrum. In previous posts we determined what a group is [link].  and what the benefits can be. We also looked into one of the biggest disadvantages and risks of working in groups and how to overcome these [link]. This post will cover one of the main purposes of having groups: Sharing Knowledge! Knowledge sharing has been around for centuries. For example, parents transferring knowledge to their children, or workers exchanging best practices. In traditional models of education, copying the knowledge and experience of a fellow classmate was generally considered a bad thing. However, nowadays in the ‘new economy’, the re-use of a colleague’s knowledge and experience is considered necessary in order to survive.

Groups & Scrum: Why we do Retrospectives

Stephan van Rooden Door: Stephan van Rooden,  10-03-2014
Onderwerp: agile  Scrum  Retrospectives  Groups  

This is the second post in a series of blogs on groups and Scrum. In the first post we defined what a group is, why people join groups and what it takes to make them a team. Establishing the stage of being a team, or nowadays in most organizations, being a Scrum team comes with some challenges. How to get this team constantly improving themselves? The Scrum Framework believes it is that important to continually improve that there is even an entire event devoted to this.

Scrum Webshop