Developing and delivering products which customers don’t want and for which there is no market can be costly. Agile can help you to efficiently develop products, but you need to know what to build. How can you find out which products your customers need?
Experimentation using for instance lean startup can help you learn about your customers and find out which features and product would be valuable. The value however comes from building products and actually delivering them to customers. You need to find ways to balance between experimentation and delivery.
The priority game is an exercise which Michael Franken did at the GOTO Amsterdam 2013 conference, to make large backlogs manageable. He showed how Scrum can help you to focus and remove waste by not making things that are probably never used by customers.
Agile teams sometimes struggle with the planning of pure technical tasks that have no direct value for the user of a system, but have to be done to deliver working software. Should you create user stories to handle such technical tasks and technical debt, or not?
A new survey, conducted by Serena Software at the recent Agile 2012 conference in Dallas, Texas has confirmed that whilst projects using Agile are working well, they could be much better and some of the biggest challenges include upsteam and downstream communication.
Bob Marshall in his new blog post, "The Value", summarises his research on different methods of prioritisation. Together with Grant Rule he developed a new way of understanding team and company goals.
Tony Wong, a project management blackbelt, enumerates some practical points on individual procutivity. This article wonders how well these apply to software development and contrasts his list with that of other lists.
Team Foundation Server 11 has added many features in the area of Application Lifecycle Management. Some of the highlights include support for code reviews, iterations/sprints, resource allocation, third part testing frameworks, and a much more capable dependency graph.
Scrum works most effectively with a prioritized product backlog. Prioritizing the backlog is part of the product owner role, but what can you do when your product owner won't prioritize the backlog because he or she doesn't see the value in prioritization?
The traditional agile approach to prioritization is that user stories of higher business value should be implemented before ones of lower business value. The concept is simple, but implementing it well relies on having a mechanism to assess business value. Pascal Van Cauwenberghe has recently described an approach to defining business value, called "Business Value Modeling", which may help.
The Scrum notion of 'backlog' is a single, prioritized list of user stories for the team to implement. This works well for organizing what the team should work on in the near term, e.g. during sprint planning. At the Orlando Scrum Gathering, Jeff Patton described story mapping. This is a way of organizing stories that provides richer context and can help with release planning.
Mishkin Berteig presents a situation where he proposed to a software development team, which just started to experiment with Scrum, to accept 2-days iterations. The approach was trying to tackle their organizational lack of prioritization resulting in constant crisis. Their decision led to a bigger crisis which exposed the need for task prioritization.