|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!