Planning for New Releases
Customers often ask me whether a feature they've requested will go into the next release of our FootPrints product. Sometimes they ask as a follow-up how we plan releases. I thought I'd say a few words about this today.
First, UniPress Software uses FootPrints to track development changes. We broadly classify issues in this FootPrints development project as Bugs, Feature Requests, and Design Flaws. When a customer or UniPress team member finds a bug, or when someone asks for a new feature, or if we determine that a feature which was done earlier was incomplete or could have been done better (a design flaw), we track it in this "Development Project."
The Development Project becomes the development team's repository for all future releases, and tickets in this project are carefully reviewed as new releases are planned.
New releases usually have a few large important features, chosen by UniPress and by customer 'vote' - when a number of customers ask for an important feature. In FootPrints 7.5, due out this Spring, a popular feature that was highly requested by customers is the FootPrints Sync Add-on, which will allow FootPrints synchronization of calendar appointments, tasks, and address book entries to third-party applications and devices such as Palm, Outlook, Blackberry and Lotus Notes. Many customers asked for this. Those of you at the FootPrints User Conference will remember the rounds of applause when I announced we were planning to do this feature.
How do we plan? First, the Development Project has a field called Projected Release, the drop down choices include the next two releases (e.g. 7.5, 8.0) and a catch-all "Future Release." When new tickets are entered, an initial determination is made on when we'll make the change. Furthermore, as we gain more data - perhaps ten customers tell us that a specific feature request is getting more important - we can move the ticket up in the release schedule. Or down.
This release determination is being done all the time, as features, design flaws and bugs are moved from one release to another.
(By the way, really custom requests, useful for only one customer for their specific installation are entered into the Development Project, but we note that this is likely a customization which will not be in a future release unless it is done as custom work.)
Also, once tickets are scheduled for a release, and developers estimate the time needed for doing the change, we can estimate the release schedule better, and we can always search and report on where we stand in getting the release closed. Once the release work is closed, we use this project to manage the test phase: Tickets are changed from Open to Testing status by a developer doing the work and then from Testing to Verified (or back to the developer!) when tested by QA engineers. This workflow process, by the way, is fully supported by the built-in customization and business rules features of FootPrints, which makes it easy to manage our development activities.
So in closing, every version of FootPrints - large and small - is directly related to the feedback from our customers and the feedback we gain throughout our support processes. This helps us keep pace with our customers changing needs and ultimately build better software.
I hope this is useful information. Email me if you have any thoughts or questions.
Mark