Product Backlogs with Process Maps or Story Maps

by Ben Linders on  Apr 11, 2013

When you have a large backlog with many user stories, structuring a product backlog with story maps or process maps can help to keep an overview and see the bigger picture.

The Planning Poker Prevents Fallacies in Effort Estimates

by Michael Stal on  Aug 10, 2012 15

In his recent blog posting “Planning Poker: Avoiding Fallacies in Effort Estimate” Hayim Makabee discusses a common problem of effort estimation called planning fallacy and why planning poker helps to avoid it.

The right time for decision making

by Marta Jasinska on  Jun 28, 2012 1

Earlier this week Jim Bird from BIDS Trading Technologies posted a blog article about the differences between Agile and Lean approaches to planning and decision making.

Seven Options for Handling Interruptions on Agile Teams

by Craig Smith on  Jan 26, 2012 1

Interruptions are something that every team has to deal with and, if not managed appropriately, they can potentially have a detrimental affect on their ability to deliver. In a recent post on the Agile Advice blog, Mishkin Berteig described seven options that teams could consider to deal with interruptions when using Scrum or iterative Agile approaches.

Do We Need an Iteration Zero?

by Vikas Hazrati on  Jun 07, 2011 1

There are usually multiple things which need to be done before the start of a project. Teams usually use 'Iteration Zero' to put all necessary systems in place in order to start delivering business value in subsequent iterations. Is this the right way?

How Should a Product Owner Participate in a Planning Poker Session?

by Dan Puckett on  Aug 09, 2010

During planning poker, a product owner should explain the user stories to the development team, but he or she should not try to unduly influence the development team's estimates.

Do Story Points Relate to Complexity or Time?

by Vikas Hazrati on  Jul 06, 2010 7

Many Agile teams use the terms Story points and Complexity points interchangeably. Agile teams believe that they are better than hours just because they are based on complexity and relative size. Mike Cohn suggested that it is wrong to use story points to depict the complexity of developing a feature, they are all about the effort.

What is Story Point? Are they Necessary?

by Mark Levison on  Mar 05, 2010 5

Michael de la Maza asks the question what exactly is a Story Point? He went looking for an answer and found many: “Story points represent nebulous units of time.” or “Story point is a random measure used by Scrum teams. This is used to measure the effort required to implement a story.”

Estimating Business Value

by Chris Sims on  Jan 04, 2010 2

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.

Sprint Planning: Story Points Versus Hours

by Vikas Hazrati on  Sep 22, 2009 11

There is a constant, long drawn debate on the benefits of using either story points or hours for sprint planning. Mike Cohn is big on breaking User Stories down into tasks, which are then estimated in hours. Jeff Sutherland on the other hand suggested that some of the best teams that he has worked with burn down story points.

Throw Away Your Bug Tracking System?

by Mike Bria on  Mar 18, 2009 5

Elisabeth Hendrickson, A.K.A "testObsessed", presents a thought-provoking stance on triaging bugs in an agile project. She discusses her feelings that problems found during the iteration are not "bugs", that only the Product Owner has the right to call something "bug", and that a healthy agile team might likely have no need for a bug tracking system.

Presentation: Planning with a Large Distributed Team

by Abel Avram on  Oct 19, 2008 1

In this presentation filmed during Agile 2008, Wes Williams and Mike Stout share their recent experience with a large distributed team, the planning hurdles they encountered and how they passed them, and their recommendation: avoid large distributed teams.

Presentation: Prioritizing Your Product Backlog

by Geoffrey Wiseman on  Oct 06, 2008 3

Choosing the right features can make the difference between the success and failure of a software product. Mike Cohn presented 'Prioritizing your Project Backlog' at Agile 2008 on how a project backlog should be organized and prioritized and non-financial techniques for prioritization such as kano analysis, theme screening/scoring, relative weighting and analytic hierarchy process.

What is Sprint Zero? Why was it Introduced?

by Mark Levison on  Sep 25, 2008 14

Some teams use a Sprint 0 to prepare their product backlog, the infrastructure (development environment, CI server), ... .Is this part of Scrum? Is it useful?

Prioritizing (the Backlog) For Profit

by Derek Longmuir on  Aug 08, 2008

Having difficulty prioritizing the backlog? Luke Hohmann has described a method to make quantitative decisions about which backlog items should be considered first. In addition to the usual attributes such as implementation effort, Luke suggested adding attributes to measure stakeholders needs, strategic alignment and to ask whether the item is driving profit.

General Feedback
Marketing and all content copyright © 2006-2015 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy