Great post by Martin Fowler about a hidden aspect of the User Story flow within a team. Many times I see teams that expect the Product Owner to behave just like a Requirements manager did in the past. Come up with the content, put it in the tool and stay out of the way! That’s …
I have, for many years, been working in software development and for about 6 years with Agile Software Development adoption. First as a project manager and later driving the adoption of Agile in the organizations where I’ve worked. One clear characteristic has become clear to me over time. You may not hear about it much …
Some time ago I wrote a post supporting the idea of a new template for the User Story. In that post I tried to explain why we should bring the “value” (because) clause to the fore, to make it the most important clause of the User Story template. Then John Arrowwood commented on that post …
Ari Jaaksi from maemo.org is blogging about Scrum in Nokia’s Linux/Open source projects.Also, Juha-Markus Aalto (of Object development fame) presented what I would call the “Nokia Agile Requirements Model” (and what Dean Leffingwell calls “Lean, Scalable Requirements Model“) at the Object days in Tampere. See the slides here(PDF alert). With all of this I can …
Thinking back to how we value our work, we must recognize that, in software, quantity is not value! The number of things we do in a sprint does not vary too much, we can consider it a Gaussian (assuming correct and consistent measurement) — or in Black Swan (TBS) parlance: velocity is a variable from …
Karl follows up on a post by Liz Keogh about the fact that User Stories need to have a different format. The original format was: As a <customer role> I want <functionality> because <customer value explanation>. Before explaining the new format let me dissect a little bit this old format. Why is it wrong? Clearly …
In this post, Jason explains one common problem with the estimation and planning sessions in Agile teams. The problem he describes however, is quite common and has lead to implementation of the Separate Design and Requirements anti-pattern in the traditional software development world.So I thought I’d write a pattern about a simple and common solution …
The people that convinced us to never mix design with requirements may have wrecked more software projects and destroyed more value in the software industry than anyone else! Just think what happens when you separate requirements from design: You don’t validate assumptions to more than a very superficial level (the “I don’t care about the …
