BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Planning Content on InfoQ

  • Scrum Project Management Practices Support the CMMI

    An exploration on how project management with Scrum and the project management process areas of the Capability Maturity Model Integration for Development are related.

  • Product Backlogs with Process Maps or Story Maps

    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

    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

    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

    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?

    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?

    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?

    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?

    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

    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

    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?

    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

    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

    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?

    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?

BT