Using Ketura to Manage Software Development

Ketura is flexible and so can be tailored as needed for different kinds of organizations. This article describes some of the possible approaches to using Ketura for managing software development. It has broader application to any industry where projects have multiple distinct release cycles, and you can choose to follow as many or as few of these guidelines as makes sense for your work.

This article assumes a good understanding of Ketura concepts and operation. For important background information, see the Start Here topic.

Basic principles

This section sets out some simple guidelines for choosing and using projects, topics, milestones, etc.

Projects

Use a separate Ketura project for each ‘product’ that you produce, including various internal ‘products’ (and services) such as your public website, intranet, etc. In this context, ‘product’ can be defined very broadly to mean any significant activity that you wish to manage.

Issue topics

Create a separate topic for each of the major components that make up your products.

It might be appropriate to treat some smaller products as a single component. In those cases, you can therefore use just one topic for each project (perhaps by letting Ketura create a default topic and workflow when you create a new project). Using topics in this way, bugs and enhancement requests can be captured for the different things in which you are interested.

Handling new issues

Make use of the ‘O1 – Review New Issues’ milestone (remember, the ‘O’ stands for ‘Ongoing’), which is added by default to new projects. Configure Ketura workflow to put new issues of various topics into the appropriate project’s ‘O1’ milestone.

You can use a task set and workflow automatically to add a task assigned to the relevant product manager to each new issue when it is created. This means that the appropriate person has the responsibility of deciding what to do with the issue.

In general, a product or project manager will deal with new issues by rejecting, deferring, or accepting and scheduling them for a particular milestone.

Scheduling an issue for a particular milestone is simply a matter of visiting that issue’s Schedule tab and using the Reschedule issue section to move the issue to the appropriate milestone, change its state from ‘Review New Issue’ to something like ‘Pending Resolution’, and then assigning any unassigned tasks (automatically added to the issue by the configured workflow) to the person who will be undertaking the initial work on the issue.

Don’t forget that you can process multiple issues in batches, by visiting the ‘O1’ milestone’s Issues tab, selecting some issues, and clicking the Act On... button.

If you want to process multiple issues in the ‘O1’ milestone individually, you can visit the milestone issue list and quickly open up each issue in a separate tab in your web browser. You can then work through the open tabs, closing each one when you have finished with a particular issue. This is a very quick way to process and schedule a great many issues.

Release milestones

Use a milestone M1, M2, etc, corresponding to each public release of the product that is to be made. Thus, the issues resolved in a particular milestone can be used directly as a basis for the release notes created for a given release.

When a release milestone is being worked upon, give it a name such as ‘M3 - Next Release’. When it is complete, rename it with the version of the public release that was made. e.g. ‘M3 - Merge 2008.1200 Release’.

Having a separate milestone for each project release gives you a lot of the information your project managers will be seeking. You can look at the Milestones tab of a project page, and see in one place the start and end times of all of the milestones (i.e. releases) of the project. Drilling down into an individual milestone, you can see on the Activity tab the amount of work undertaken and its cost, either for the whole milestone (release) or for a particular portion of time. The work and cost is broken down both by user and issue. Of course, Ketura gives you schedule, work effort and cost predictions, as well as information about what has already happened.

Create issues on a particular release milestone for all the activity involved in the release, including testing and management. That way, you can see the time taken by every team member for the release.

Handling issues that apply to multiple products or milestones

Sometimes, a change needs to be made on one product and also propagated to another. Create two issues in such cases. The first issue is to implement the change on one product. The second issue is to propagate the change to the other product. That way, you can accurately track the costs and work effort and assign them to the appropriate products.

Recording issues that you don’t want to schedule right away

Use the ‘X1 - Deferred Issues’ milestone, which is added to new projects by default. It can contain, for example, enhancement requests made by customers that you don’t want to forget, but that you haven’t yet planned to implement. Make sure all such deferred issues on that milestone are in an inactive ‘Deferred’ issue state, so Ketura does not count them when calculating schedule predictions for a particular project.

Keep an eye on the ‘Trends’ tab

When working towards a milestone, it is helpful to keep an eye on the Trends tab. This can act as a useful reality check on over-optimistic schedule predictions. Ideally, you wish to see the Expected Remaining line trending towards 0 at an appropriate point in time (the completion date for your project). If it is not, then that can be a good indication that all is not well.

Use Ketura’s tools to keep a project on track

Ketura provides a number of ways of managing a particular milestone/release that does not look like it is going hit a desired deadline. These are discussed in the Ketura Tour Step 5: Keeping Projects On-Track.

Use issue states and workflow to implement your procedures

Defined separate issue states to correspond to the various stages of the procedures by which you handle issues. Use Ketura’s workflow to enforce issue state transitions, to ensure that an issue passes through particular states. For example, you can ensure that an issue passes through a ‘Testing’ state before being marked as ‘Resolved’.

Modelling phases in your project’s lifecycle

Some organizations model their projects using phases, such as initiation, envisioning, planning, developing, stabilizing and deploying. These can be mapped to Ketura in a number of ways, depending upon how you want to manage your release lifecycle.

Use issues and tasks to model real activities

Broadly, if there is an activity that needs to be performed, it should probably be modelled with a suitable issue and/or tasks. This includes project management activities.

Thus, you might start out with issues to ‘Gather requirements’, ‘Document specification’, ‘Document design’ and so on. At some point, you would end up with a set of issues that related to the actual implementation. During the course of implementation, further issues (bug reports, enhancement requests, etc) will probably be created and scheduled.

Because you can view the milestone issue list with completed issues filtered out, this approach actually works well and you won’t find yourself becoming distracted by issues relating to earlier project phases.

Involve developers in the work estimation process

It can be very helpful to involve the developers in the process of estimating how long it will take to implement the issues for which they have remaining work. If you are working within strictly defined phases, you might have a separate issue (with a task for each developer) to update the tasks assigned to them in the milestone with work effort estimates. That probably isn’t ideal in terms of management overhead, though, and, you might instead model this with workflow state transitions. Working that way, a newly-scheduled issue might be placed into an ‘Estimation’ state, with workflow to add a task to ‘Identify scope of issue and update issue tasks with work estimates’, or some such. As a project manager, you might then require all issues to be progressed out of the ‘Estimation’ state and into a ‘Pending Resolution’ state before allowing the next phase to begin.

If you wish to be a little less formal than that, simply have an ‘Identify scope of issue and update issue tasks with work estimates’ task as part of the task set automatically added when an issue enters ‘Pending Resolution’ state. That task set could also include a series of pre-canned tasks that are your standard way of resolving a software-development related issue. When an issue is scheduled to the milestone, ask the developers to update the work effort estimates on those issues. This type of informal approach can work very well with smaller development teams, but you can choose a level of formality appropriate to your situation.

Use issue types

It is worth noting that you have complete control over the types of issue in the system. You can, for example, have a ‘Requirement’ issue type if you wished to capture each requirement as a Ketura issue. You can filter most issue lists by type, so it would be easy to see just the results of a ‘Requirements’ phase on a particular milestone.

Consider your options

Although the above discussion leaned in the direction of one milestone for each release, there is nothing in Ketura that constrains you to that. You might find that having a separate milestone for each phase of development works better for you. That way, you would only progress to the next phase when you were happy that the previous one had been completed. You would formally progress to a phase by making its milestone ‘current’. You could use milestone naming to group the phases of a particular release together. For example, you might have the following related milestones:

Next Release: Initiation Phase
Next Release: Envisioning Phase
Next Release: Planning Phase
...

You have complete flexibility to decide how best to use Ketura’s milestones to accomplish your goals.

Summary

There are several different ways you can handle different phases in your project’s life. Ketura gives you a toolbox of possibilities that you can use these in whatever way you think will work best for you.

Be creative with workflow, but walk before you run

Most people find it easier to start off using Ketura without too much workflow defined. Once you have a good idea of what you find yourself doing repeatedly, you can define workflow accordingly.

It is important to keep an open mind about how you use Ketura. The system has been designed to try to keep out of your way and not impose too much overhead on its users. If anything starts to become cumbersome, it is often a sign that the workflow, or some other aspect of how you have decided to use the system, is somewhat suboptimal.

Fine-grained workflow

Is there a way of having two kinds of issues with different ‘workflow’ or ‘state transitions’? For example, one set for the bugs and features and another for the project management controls and deliverables associated with each release?

In the current release of Ketura, workflow is largely defined by issue topic. You can therefore have completely different workflow for different topics (you can also copy workflow from one topic to another). There is nothing to stop you from having different issue topics related to the same product or service. For example, you might have the following issue topics relating to a product ‘P’:

P – Development
P – Project Management
P – Marketing

As well as having separate topics for things such as the marketing and development for a given product, you might consider managing marketing activity on a separate project altogether from development activity. Even if you kept them together, issues of all three ‘P’ topics above could be managed within the same overall project and milestones, but each would have completely separate (topic-related) workflow.

Thus, the allowable state transitions for each topic could be different, and issues of each topic could be put automatically into different ‘Review New Issues’ milestones upon creation (if you wanted a separate milestone for each, which you might not). Likewise, the initial automatically added ‘Review New Issue’ task (or tasks) could be assigned to a different person for each topic.

Another way of handling this sort of scenario is to use a single issue topic, but have a more complex set of state transitions. Thus, new issues would start off in a ‘New’ state or some such, and could then be transitioned into a ‘Pending Development’, ‘Pending Project Management’ or ‘Pending Marketing’ state. The allowable state transitions from each of those could be entirely separate. This isn’t necessarily the best way of arranging things, but it is certainly an option.