Mike Cohn raises an interesting and topical issue about how to indicate what you are working on at a daily stand-up meeting.
In our project we are currently working on an iteration where all the stories overlap and interact. Our usual approach is that each developer grabs a story and works on it until its done, then repeats until either the iteration ends or we run out of scheduled stories. In this case we need something a little smarter – some way of grouping the tasks for the iteration, regardless of which stories they “belong” to, so that developers can work on a chunk of related functionality rather than a story as such.
This is potentially risky, as some of the commenters on the above post point out, but at the moment I can’t see a way around the problem.
Should the Daily Standup Be Person-by-Person or Story-by-Story? | Mike Cohn’s Blog – Succeeding With Agile™
From time to time I toy with the idea of writing a book. One of the things which has put me off is the whole “big project” nature of the task. I am so used to test-driven, small-iteration, early-value working that slogging away for six months or a year on a single task seems particularly daunting.
An interesting possible solution to this is the idea of writing in an agile manner.
InfoQ: Can Authors Use Agile Methods?
It must be that end-to-end software production process is on my mind. I keep spotting interesting articles about the topic. Here’s one from Digital Dim Sum which delves into the way that requirements find their way into development, contrasting a “push” of requirements with a “pull” of information..
Don’t push requirements – pull information | Digital Dim Sum
My favourite process at the moment is a more “pull”-centred process than many I have seen. Anyone is free to write and contribute “user stories” at any time. From time to time ones which seem valuable are pulled into a “planning poker” game for estimation. Before each iteration of work, a mixed group of stakeholders gets together to pull a fixed amount of development effort from the pool of available estimated stories into the next iteration schedule. Developers then pull stories from those scheduled for the iteration, work on them and place them in a pool of implemented stories. When the integration test team are ready, they pull a build containing stories implemented so far and test it. Meanwhile the customer deployment team may pull and deploy any tested build at any time.
As an abstract process this seems streamlined but there may, of course, be practical issues.
A short article about planning and organising a project using post-its and/or a spreadsheet to associate tasks with phases. The interesting thing about this article for me is the explicit mention that the process is cyclic and iterative, rather than linear. Tasks are expected to move around the phases in a variety of directions, and special “evaluation” phases are provided as stopping points between other parts of the process.
Planning
Estimation for agile processes is a bit of an odd duck. One the one hand it needs to be done before work starts, but on the other hand, the more such stuff is done before work starts, the less agile the process becomes. To overcome this apparent contradiction, several people have tried to devise more “agile” ways of estimating work.
One of these approaches is Planning Poker. See also AGILE IN ACTION: XPDAY2006: Experiments in Agile Estimation
It’s nice to see some continuous improvement in action. This article describes how one team decided to change the way they use their task board to better make use of the communication ad feedback it offers.
AGILE IN ACTION: We changed the layout of our planning boards
One fairly familiar way of writing requirement stories is “as a … I want … so that …”. Elizabeth Keough reckons this is not quite right.
sirenian: RIP As a… I want… So that…