Archive for category customization
Kanban: Why 3 States in Cumulative Flow Diagram
Posted by Olga Kouzina in customization, help desk on March 22nd, 2010
We have implemented cumulative flow diagram in TargetProcess v 2.15 as a tracking/reporting chart to get a quick overview of user stories in To Do, In Progress and Completed state:

Why we have only 3 fixed states for cumulative flow diagram while all the states for User Stories and other entities are customizable? We could have enabled showing the count of User Stories in all the customized states, be it 6 or 7 or 8 states. But the visual diagram would have been too clogged this way. We had to either follow the reporting stats meticulously, replicate all the states and counts in the digram and lose the visual UX of this chart, or to get it down to 3 basic states such as ToDo, InProgress and Completed (all the customized states are just a variation for those 3 states, one way or another) and retain a good info-design.
Some people asked us to enable more detailed views in cumulative flow digram and we will consider implementing this in the future.
You’re welcome to submit your requests on cumulative flow diagram and other features to TargetProcess HelpDesk or to TargetProcess UX Group.
How To Create ANY Custom Workflow with TargetProcess
Posted by Olga Kouzina in customization, howto on January 29th, 2010
TargetProcess allows to create virtually ANY custom workflow. What you need is a little bit of thinking and creative approach.
Let’s look at the communication thread below:
Customer:I want to add a custom field to the story template; I would also like it to be (or not to be) a certain value for the story to be able to be marked done. Thanks.
TargetProcess Team: Can you give us an example of what you’re looking for this custom field to be, please?
Customer: I want to make sure that documentation is written before the story is closed. So maybe radio buttons? It could start as “needs documentation” then have options of “documentation written” or “documentation n/a,” both of which could be chosen for the case to be able to be closed.
TargetProcess Team: Unfortunately, TargetProcess doesn’t allow you to create such a “dependency” on the state of an entity. But you may create custom fields that are “required” fields; forcing someone to pick the status of the documentation (needs, written, or n/a) upon the creation of a user story. You could include “needs doc” as a state before “closed”.
As you see, basically, you could juggle with custom fields and custom states to get what you need.
How to Use Custom Reports to Generate Efforts and Cost Totals in TargetProcess
Posted by Michael Dubakov in customization, howto, report, report engine on May 12th, 2009
Quite often we’re asked questions on how to align TargetProcess agile framework with down-to-earth life — like expenses forecast, sum of efforts based on resource usage for each particular activity, the total cost of the project. These items sound more MS Project like (check what we think of MS Project) but we give credit to the real business needs and in this post we’ll share a technique to get those reports and calculations.
Suppose, you’re planning a project. You need to calculate the efforts and costs for QA, implementation, deployment to production, post production support etc. Each user story has all these stages, but they intertwine without following each other linearly (read more on the benefits of feature-based development vs. stage-based development )
To track these activities/stages across an iteration or a release, you can create tasks within a user story, like here:

You can create custom report that will calculate total time for Specification, Development, Testing, Test Cases across iteration. Here’s how:

And here’s the report:

Time reports can be used for cost calculations based on an hourly rate.
You’re welcome to comment and contact us with questions about your particular custom reporting case.
Enjoy Customizability: Plugins, Bugzilla Integration and Custom Fields per Process in TargetProcess v.2.8
Posted by Michael Dubakov in customization, plugin on March 16th, 2008
TargetProcess v.2.8 release took longer than expected. The reason as always is changing requirements
When we planned release roadmap we thought Bugzilla integration going to be easy and release will be quick. But when development started, we decided to add Plugins Framework into TargetProcess.
Why? We have many requests about different features. If we will implement them all, it will kill the product. Moreover, it will take YEARS to implement at least half of them. Plugins give us flexibility. In many cases we will not say “No, we think this feature is not required to other customers and will not implement it“. Instead we may say “Ok, if you need it you have two options: implement it as a plugin or request customization service and we will create the plugin for you“. Sounds better, isn’t it? And it do resolve the unique problem that company has.
So far plugins allows you to operate with business logic only. There are no API for UI widgets you can create, but we will add them in future. Still plugins framework provides a real customization power:
- You may influence entities workflow and do literally any action you want.
- You may integrate with almost any external system (for example, now integration with another bug tracking tool will take about a week!).
- You may create specific reports and gather required data.
There are many possible applications, creativity is enormous thing when it is supported by flexibility.
That was a big addition and it took time to implement and polish. Still we don’t even expect it is complete neither “perfect”. We pretty sure that first real usages will show us the best road for improvements.
Bugzilla integration was implemented as the first real plugin. It synchronizes bugs in Bugzilla and TargetProcess, thus separating bug tracking and planning concerns (use right tool for right job). The plugin provided with full source code, so you may customize it as required.
Other significant improvement is better custom fields support (look, almost all new features are about flexibility!) Now custom fields may be defined for each process. One team may define Risk for user story, while another doesn’t. Now TargetProcess supports that. Custom fields were added into Custom Reports (they have similar names, it would be the crime to not integrate them). Also custom fields now visible in ToDo list and in Iteration plan (with filters).
As a final note, we fixed more than 50 issues in v.2.8. Most of them are small, but annoying (for example, semicolon separator in CSV export or filters remembering in Iteration Plan).
BTW, we have nice plans for v.2.8 like Visual Studio plugin and Test Track Pro integration. Enjoy the trip!
Plugins Support in TargetProcess v.2.8
Posted by Michael Dubakov in customization, plugin on February 11th, 2008
It will be possible to create custom plugins in the next release of TargetProcess. We’ve already created plugins architecture and are polishing some things at the moment. Plugins developers will be provided with С# API and some samples (Bugzilla Integration is a plugin itself for example and it will be released as an open source project).
As a plugin developer you will be able to:
- Subscribe to different events in TargetProcess and do some actions.
- Schedule plugin execution (for example, each 10 minutes)
- Create different settings for plugins for different projects and different processes
As we see, this opens huge customization abilities for TargetProcess. Some examples of useful plugins:
- Change Request state to Closed when correspondent Bug or User Story closed
- Create a report and email it to a team lead each Friday
- Post new bugs or update existing bugs to third-party bug tracking application that has web services API
We are going to build a community around plugins implementation for TargetProcess and support it with all answers, samples, implementation and development. Stay tuned!

Recent Comments