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?
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.
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.
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.”
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.
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.
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.
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.
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.
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?
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.
TargetProcess has released a free 5-user Community Edition of its Agile project management software. The Community Edition contains the same features as the full edition of the product with two limitations: a maximum 5 users, and no support.
On April 15th Thoughtworks will release Mingle 2.0, nine months after the initial release of Mingle. InfoQ got some time with product manager Adam Monago to talk through the new functionality provided by Mingle 2.0.
Danube Technologies has just released the 3.0 Release of ScrumWorks Pro, last mentioned in August 07. ScrumWorks Pro is an Agile Project Management tool that help track team(s) progress through individual iterations and whole releases. In this release changes focused on two areas: usability improvements and the use of MySQL as the backend database.
The involvement of customer in an Agile project is taken for granted, however in many situations, intentionally or unintentionally, the customer may not follow the Agile practices. An interesting discussion on the Extreme Programming group tries to decipher the situation and find possible solutions.