Win a copy of TDD for a Shopping Website LiveProject this week in the Testing forum!

Dave Churchville

+ Follow
since Jun 07, 2004
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dave Churchville

Originally posted by Frank Carver:

Even my small stories tend to have business value, because I split each conceptual larger story in a different way. Where the EP demo has "UI" and "storage" as tasks withing "create shopping cart", my approach would be to divide it into much smaller business-value stories such as "show cart button takes the user to a shopping cart screen", "shopping cart screen shows user id", "shopping cart screen shows list of items", "initial shopping cart is empty", "buy button adds an item to shopping cart list", "delete button removes an item from shopping cart list", "clear button removes all items from shopping cart list", "checkout button takes the user to a purchase screen", "purchase screen shows same items as the cart list", and so on.

It appears to me that the EP demo splits the large task "horizontally", where I guess I would try to split it "vertically".

Some or all of these small stories may involve back-end storage, session management, or whatever, but that's a technical aspect which is glossed over in the stories. If a story (such as "show cart button takes the user to a shopping cart screen") obviously does not need back-end storage, then don't code it. Deliver the story and move on. The key point is that they all provide separate business value and can be prioritised and/or omitted for any given release.

Co-incidentally, I also find that this style of story aligns much more intuitively with the acceptance tests. Writing sensible acceptance tests for a large story such as "shopping cart" is not an easy job, and can often descend into a lot of man-hours spent in meetings and wrestling with documents. The acceptance test for "checkout button takes the user to a purchase screen" is almost too obvious.

Does anyone else work like this? Are there any obvious or subtle problems I'm missing?

Interesting point, Frank.

I don't see any problem with your approach, you're just using a smaller granularity of story, which I agree can make things simpler both to discuss and to implement.

The point is really that it's the customer that should be writing stories (with help from the development team) that are meaningful to them.

The developers are free to subdivide into whatever tasks are meaningful to them (or not).

From my own experience, it can be difficult for customers to directly prioritize very small stories. In this case, you might want to categorize a set of small stories into a "topic" or "theme", and have the customer first prioritize high level topics, then figure out which subset of stories make sense.

"Shopping Cart" might be top priority, for example, followed by "Accept Credit Cards" as topics, each with 5 or 10 stories under each.

It's also pretty desitable to create stories that can stand alone as useful business functions, or can be omitted without making other stories useless.

Thanks for the great discussion here.
Thanks Ilja, you've pretty much answered the way I would have :-)


Another way you could approach this is to skip the tasks altogether and use fine-grained stories with business value, as long as "the customer" can understand and prioritize these. This might be a good approach if you are the lone developer.

Then you'd simply create acceptance tests for each small story and mark them as passed. I actually prefer smaller stories, since the estimates tend not to get as far off as larger stories. My personal rule of thumb is to limit the size to about 1 week or less of work.

Tasks are a mechanism for developers to crystallize their understanding of a story and how they will implement it. They are also a way to divide work if more than one person/pair will be working on the story.

The main issue I see with conflating stories and tasks is that if you are not the customer, it gets increasingly difficult to talk about "Customer acceptance tests" for technical details like creating database schemas, doing refactoring on the FooBaz class or "writing the Hibernate integration wrapper".

Originally posted by Gregg Bolinger:
I am new to agile methods. I've been reading up on it and trying to decide if it's right for me and whether or not I should persue it further. How easy is it to jump in with EP and use it in this type of scenerio? And also, do you think that using EP would help someone get a better feel for using agile methodologies on a regular basis?


Hi Gregg,

I think it's fairly easy to get started with ExtremePlanner, regardless of your experience level with Agile.

In fact, I think the planning aspects of Agile are the easiest to grasp, since we've all done prioritization of activities within a fixed time period at some point in our lives.

For example, if you have 2 hours to kill before you meet a friend for lunch on the weekend, and a backlog of chores around the house, it might look like:

1. Do a load of laundry (1 hour)
2. Clean out the garage (3 hours)
3. Sharpen video game skills (1 hour)
4. Eat pre-lunch snack (15 min)

Assuming you have nothing clean to wear and are pretty hungry, you'd prioritize the laundry and snack, and maybe "split" a story like cleaning the garage into a managable 45 minute chunk by adding "Sweep garage floor and scrape off weird sticky things".

That's really all Agile planning is about: priortitizing, estimating, and being creative about fitting the work into fixed time periods.

ExtremePlanner makes it easy to create a backlog of stories, create fixed-time period iterations, and do your planning. You can use as much or as little of the functionality as you're comfortable with.

I usually recommend that people new to Agile start out with whiteboarding or paper-based methods, just to get very comfortable with the "time to kill before lunch" kind of planning without relying on software. Generally you'll either feel the need for software to support you after you know what's involved, or you'll decide that whiteboarding is enough.

Of course, if you already have distributed customers or colleagues, then you might get immediate benefit from using software earlier.

Hope that helps.

Originally posted by Frank Carver:

You wrote: tests are defined against Stories, not Tasks

Is there any particular reason for this? In particular, how do you know that as task has been completed if there are no tests for it?

Taking the tasks in your demo as examples, the "add a product to my shopping cart" story has two tasks "create shopping cart list user interface" and "implement shopping cart storage code". The tests and implementation for these tasks seem very different and could easily be done by different users/pairs.

So what happens if one task is complete but the other isn't? How does Extreme Planner know? it just seems strange that Extreme Planner is not able to access or manage information about the test status of tasks.

Perhaps I'm missing the point here, though, can you clarify how it is supposed to work?

[ October 12, 2006: Message edited by: Frank Carver ]

Hi Frank,

Perhaps the meaning of "test" here needs definition. Stories have "acceptance tests" which test the entirety of the feature. That is what ExtremePlanner is tracking.

So for "Add Product to Shopping Cart", I might write a test like "Add a single product and verify that it displays the product name and quantity in an on-screen cart". When this feature is complete, this test should pass, regardless of the implementation.

You might also have automated unit tests for specific code modules, classes, etc., but ExtremePlanner doesn't track unit tests.

So yes, multiple users/pairs could work on tasks for the same story, but at the end of the day, all acceptance tests need to pass for that story, and the status of individual tasks isn't very important in that context.

In fact, what winds up happening (at least in my experience), is that some tasks get removed, others get added, but the tests are fairly stable, since they are direct consequences of the requirements, where the tasks are pretty implementation dependent.

Does that make sense to you?

You might find Ron Jeffries short article "Card, Conversation, Confirmation" relevant to this topic also:

Originally posted by Atul Shinkar:
Thanks a lot SIR
The information you provided was really good.
I again want to ask you one more question that does "ExtremePlanner" follows any SDLC Model or it itself is a new SDLC Model?

Atul Shinkar

ExtremePlanner is not itself an SDLC (software development life cycle), but can be used to support most iterative development processes.

Most of the features were designed to support Agile processes such as Extreme Programming ( and Scrum (

These processes have in common the idea of an iterative approach to development. Frequent, consistent delivery of running, tested features that add the most business value (as determined by the customer).

A typical Agile development cycle looks like this:

1. Release Planning - prioritize the backlog of features and choose the highest priority ones that we have the capacity to implement by a certain date

2. Iteration Planning - given a set of priorities, choose a subset that we can get done in the next 2 to 4 weeks. Break features down into development tasks and write acceptance tests for the upcoming features to be implemented.

3. Development and Daily Standups - in the middle of an iteration developers do a little design, a little implementation, a little testing, and a little code review. Each day the team meets very briefly to discuss what they completed previously, what they are working on next, and any obstacles.

4. Iteration Review - At the end of an iteration, the team demonstrates completed, tested, working functionality to the customer to get feedback and direction. At this time the customer can request new features and re-prioritize the backlog before the next iteration begins.

5. Retrospective - Team discusses what's working well and what needs improvement (need more naps, better test coverage, shorter meetings, etc.)

6. Repeat steps 2 - 5 until the release, take a few days to recharge, then start from step 1 again.

Originally posted by Frank Carver:
Compared with some of the "web 2.0" applications we see these days, Extreme Planner seems very "old school". Personally I don't mind that it doesn't use AJAX, but I am slightly puzzled that there seems to be no support for attaching arbitrary tags to stories or tasks.

It might just be the way I work, but I often find myself thinking in terms of tags - in the sense of attributes which cut across the regular story/task hierarchy. For example, I might have a bunch of tasks which I tag with "web services" so that anyone keeping an eye on web-service related things can select just those. Similarly I might tag a bunch of stories with "performance" or "database", or whatever. And, of course, some stories or tasks might get more than one tag.

Maybe EP has support for this sort of functionality, but if so, I couldn't see it in the demo.


Well, "tagging" isn't something that's supported in the current version, but I agree that that might be a useful addition.

ExtremePlanner does support a "Topic" which can be used to group related stories together, and can also be searched (in addition to the actual story name). So a basic form of categorizing is available, but not to the extent you're talking about.

It's certainly an interesting idea for an enhancement, though.

As far as AJAX/Web 2.0, we're certainly more than capable of using the technology, but our philosophy has been to keep things simple and accessible to the largest cross-section of browsers possible. Fewer quirks, less frustration for our users (and for us as well ;-) I'm sure there will be opportunities to implement AJAX in the future in some area of the application, but we'll do it with restraint.

Thanks for the ideas.

Originally posted by Frank Carver:
I just took a look at the demo installation of Extreme Planner, and in general it seems fairly well organized. One thing which struck me, though, is that many things which I would expect to be links are not.

For example, on the Iteration Status view a failed test lights up in red, but no indication of which test has failed - I tried to click the fail message to "drill down", but no such luck.

Similarly, for some of the tasks there is a label which states "No tests defined", but nothing to click to define a test for that task. I spent a few minutes looking in lots of places, but could still not find where to define a new test.

And again, on the same screen, tasks are shown as assigned to spacific users, but the user name is not a link - it neither takes a user to a page about that user, or (probably more useful) a page which shows all the tasks currently assigned to that user, and their status.

When I go to the list of tasks page, the iterations are not clickable, the users are not clickable, and neither are the status values.

I could go on, but I hope you get the message. To me, leaving all these things as un-clickable text is a real waste of user-interface space. An application which users love (rather than just tolerate) is one which works the way they want, rather than forcing a different model.

Any chance of this changing?

Hi Frank,

That's useful input. In most cases where something *isn't* clickable, its because there is no obvious screen or view to navigate to, or we were afraid of too much noise on the screen (i.e. every data column in a list having a link).

In the specific case of the Iteration View, tests are defined against Stories, not Tasks, so clicking the Story Name will take you to a place where you can define Tests, more Tasks, etc. It might be useful to also make the message link to story tests as well.

But your point is taken, that it might be better to have the option to navigate however you like, versus having only specific paths defined.

As we continue to update the application, we'll keep these kinds of navigation issues in mind. Your specific suggestions about the User link and the Tests link sound like good candidates for the iteration status view.

Originally posted by Atul Shinkar:
Hello ALL

Can anybody please tell me the difference between the ExtremePlanner & FileNet's Team Collaboration Manager which was introduced in their new P8 suite.

Atul Shinkar

Well, I don't know anything about FileNet's products, but according to their website:

"It provides the contextual framework and collaboration tools, including discussion forums, live meetings, and interactive polls, to enable group members to share information and participate in processes to facilitate group decision-making."

ExtremePlanner does not do discussion forums, live meetings or interactive polls, so I'm pretty sure that would be one major difference :-)

What it does do is help agile software teams track user stories (features or defects) through multiple planning cycles (iterations) and delivery to customers (releases).

Hope that helps, at least a little bit.

Originally posted by vishwanath nadimpally:
Hi Dave,

I just took a 1 minute tour of ExtremePlanner and my first impression was 'Mercury ITG'. I used to work at Mercury interactive where we built this custom project management tool called ITG, which works with Kintana. What are the advantages of ExtremePlanner over other such products.

Sorry, I'm not familiar with Mercury ITG, so I can't really tell you how ExtremePlanner compares.

In general, it's designed to be lightweight, and just handle the basic workflow of defining user stories, scheduling them into releases and iterations, dividing them into tasks and acceptance tests, and doing some basic tracking and reporting.

Originally posted by Gregg Bolinger:
Thanks. What was the decisive factor in making this tool web based? I know you mentioned you have wrapped up an eclipse plugin but are there any plans for a desktop client in the future?

Well, in our experience, the kinds of teams that get the most out of project planning software are often distributed at multiple locations. So this required either a client-server architecture, or a web-based one.

We thought that a Web-based approach would make it easy for anyone to access or update the information from anywhere without installing special software.

The Eclipse plugin is really just a simple way to let developers see what tasks they've got, and to be able to quickly update them without leaving the IDE. Since developers are the ones who need to frequently update tasks, having an integrated solution is pretty high value.

We aren't currently planning a desktop client, although there will soon be enough exposed APIs for some enterprising soul to create one for themsleves ;-)

Originally posted by Gregg Bolinger:
At some point in time, when EP first became usable, did you begin to use the tool for future development of EP? If so, did this allow you to fine tune it and find features to add/remove along the way?

How influencial has using EP been on developing EP?

Hi Gregg,

Thanks for the great question.

Actually the initial reason we developed EP was that we were frustrated with the available tools for planning and tracking development.

We were the first users, and continue to use EP for internal planning and tracking of it's own development, and that of other projects.

For example, one the things we noticed was that when working with outside customers, they occasionally wanted a hard copy or spreadsheet of the current stories being worked on. Features like the export to Excel, and to Word/RTF came from these types of interactions.

The Iteration Status view feature was another one that sort of emerged as we were looking for a simple way internally to see what was happening at a glance for the entire iteration. This view lets you see each story scheduled for the iteration, and for each one, which tasks are completed, in progress, or not yet started, and also the current status of acceptance tests.

In terms of influence, I think we sort of realized that showing restraint on adding features was probably the smartest thing we could do, both with EP and on other development projects. Too many products suffer from feature bloat and become difficult to use and to support.

We are pretty selective in terms of trying to add high value features that don't add unnecessary complexity.

Originally posted by Pete Budic:
Is there any functionality in Extreme Planner for allowing updates to be sent in via email? Or perhaps for sending links in the email to take a user to a specific story/etc?

For example, instead of just sending out a reminder to a developer to update EP with his hours completed on a certain task, could I have EP send him an email with either a link to the task or even allow him to send in his hours via the email (for the Blackberry crack addicts)?

Hi Pete,

Interesting ideas.

There isn't currently any support for this type of thing, although we've just completed an Eclipse plugin that will allow easy updates of task hours straight from the IDE for developers working in that environment.

Linking directly to a story from the email is something that will probably make it to a release in the near future.

Originally posted by Bob Gibson:
According to the prereqs (, the server side
only needs Java 1.4.2 and Tomcat 4.1+

How many users/developers can be supported?

Hi Bob,

ExtremePlanner has been designed to support thousands of users, stories, and tasks without a problem.

The default installation uses an embedded SQL database, which has been used in fairly large installations without a problem. We also support the use of MySQL 5.0 for customers who want to manage their own databases, or do external integration, etc.

Originally posted by Klaus Meucht:

Which Features doesn't Extreme Planner use, that conventional planner tools have, because agile project teams don't need this features.

Are there any features that are special for agile projects, that conventional planner tools don't have?

Klaus Meucht

Hi Klaus,

Good questions!

The main features that ExtremePlanner excludes are such items as Gantt charts, resource-leveling functions, task-level start and end-dates, and dependency tracking.

While these features have their place, we've found that most Agile teams just don't use them. And our philosophy has been to keep things as simple as possible.

In terms of features ExtremePlanner includes (not normally found in traditional PM tools), I'd say it is quite different in that planning and tracking are user story-driven rather than task-driven.

What I mean by that is that traditional planning often focuses entirely on low-level tasks, resource assignments, etc. that don't actually map to business functionality or goals.

ExtremePlanner lets you define User Stories as increments of business value that can be prioritized, estimated, and then scheduled for releases and iterations.

Unlike traditional tools that micro-managing each task with a start and end date and artifical dependencies, you manage at the iteration level (usually a 2 to 4 week period) and track the progress of stories and tasks that will lead to delivered software.

Some features that support this:

- Burn-down progress charts by release or iteration (how fast are we going?)
- Iteration status view that shows graphical status of tasks by User Story
- User Story-driven planning (stories have associated tasks, acceptance tests, file attachments, etc.)
- Configurable estimation units (hours, days, weeks, or story points)
- Acceptance test tracking

Originally posted by Jax Blunt:
Hi Dave

I'm currently working in a support environment, supporting multiple clients on multiple versions of a java based software. Would extremeplanner be able to support this type of environment ie keep track of which defects are fixed on which versions and so on?



Hi Jax,

While you could use ExtremePlanner for this purpose, there are tools better suited for this type of issue tracking and reporting across multiple clients and versions. Most traditional bug tracking applications do this quite well.

What some of our customers do is to use ExtremePlanner for release planning and tracking of work in progress, and tracking issues and resolutions in another system. We do allow some basic integration such as linking to a defect in an external system, and we'd like to do more complete integrations for specific 3rd party systems in the future.