Category: 2.2 Agile Methods

  • Agile Methods and the Magic Triangle

    In software engineering, the magic triangle is a well-known concept to illustrate the relationship between scope, time, and cost of a software development project. Of the three (scope, time, cost), pick two, and the third will magically follow. (It is determined by the other two.) Scope means features (or delivered functionality), time means duration or […]

  • Scrum’s Product Vision vs. Project Mission

    As noted previously, Scrum uses the term product to mean artifact. This is fine, as long as the user of Scrum is a software vendor, developing a product for a market. It is confusing, however, if the user is a consulting firm, performing a custom project for a client. If you are a consulting firm, […]

  • How Project vs. Product Confuses Agile Methods Terminology

    In a previous blog post I noted how the terms project and product are being confused in open source. However, it is agile methods, specifically Scrum, where it gets really bad. To recap: A project is a human undertaking to create an artifact. A project, by definition, has a start date and an end date. […]

  • There is no Product Owner

    One of the most difficult aspects of Scrum is the role of the product owner. Most software vendors have a product management function, typically split into strategic and technical product management. Technical product management is usually equated with Scrum’s product owner role, that is, the guy or gal who writes business-value-oriented user stories and epics, […]

  • Agile Feature Teams vs. Inner Source

    Agile methods reacquainted developers with the idea of working from business value rather than focusing on technical concerns only. Agile methods are therefore often equated with feature-driven development, in which work is driven by features prioritized by business value irrespective of technical consequences. This thinking can create code silos and wreak havoc on software architecture […]

  • Who Writes and Prioritizes User Stories?

    I updated this post after I realized that it is more about prioritizing user stories than it is about writing them well. In Scrum, a product owner writes user stories to capture requirements and prioritizes them in a product backlog as the upcoming work queue for developers. The main question on my mind is: Who […]