|Door:||Ron Eringa, 10-04-2014|
“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?
|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?
|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.
|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!
|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?
|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.
|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.