Blog

Everything you need to know about tinyPM. Everything we want to tell you about agile.

tinyPM 2.6.2 Released

March 20th, 2012 by Marcin Niebudek

While working hard to release tinyPM 3.0 we’ve decided to make one more release for v2.x which would include the most urgent changes. So here comes days off on iteration burn-down charts as well as a few more improvements and fixes to exports and API.

Those of you who use the releases functionality will find current release charts on all dashboards and on backlog so that you can quickly notice how the release is doing.

As always the full list of changes is available in our documentation. Download new tinyPM today!

Christmas Time and a Sneak Peeks for tinyPM 3.0

December 20th, 2011 by Marcin Niebudek

It’s been silent here recently, but for us this always means one thing… Our team must be working hard on something. And this time it’s tinyPM 3.0, so have a look at the first sneak peak to where tinyPM is heading with its new version!

The video above comes from our early walking skeleton. So what’s in there actually? We’ve decided to change a few things in UI but you will still find all what’s best in tinyPM in a new version, so the v3.0 should not be a shock to all the 2.x users.

The upcoming UI changes include:

  • more client-side behavior so that the UI responds quickly and you don’t loose your current context,
  • most of the create and edit forms will now show up in pop-ups (no more going to separate pages),
  • you will be able to choose between single- and two-column views, cards and table modes (on backlog) and 3 zoom levels of detail for stories and tasks,
  • the UI will be less cluttered and some actions will appear only in the right context (ie. after selecting some stories or tags),
  • charts will get more interactive, so that you can get even more information out of them,
  • most of the data will be editable inline (no more going to separate forms for quick changes on several stories),
  • table view will get more sorting options and (re-)tagging many stories will become no-time operation

We’re doing this and many more in the spirit of our mantra “tiny effort, perfect management“. Here are a few screen shots presenting some of the above changes. You can find more on our Facebook Page.

We hope that you are already in the Christmas mood and would like to wish you all

Happy Christmas and a Prosperous New Year!

~ tinyPM Team

tinyPM Survey Closed. We Know the Winner!

November 15th, 2011 by Marcin Niebudek

This time we’re happy to announce the winner of the book “Management 3.0″ by Jurgen Appelo which was the prize in our survey. The survey was announced among our newsletter subscribers and users that registered in our support site after downloading tinyPM.

First of all thank you for participating in the survey. We value all the feedback that you’ve given us. We are even more happy as the survey allowed also people who didn’t decide to use tinyPM to share their reasons behind that decision.

So using our advanced prize drawing tools we have found a lucky winner… It’s Chris Townsend from UK. We’ve already contacted Chris and will be shipping the book soon!

Chris indicated that they are introducing agile in their company and don’t know yet how it will go. We are sure the book will give them lots of new hints as well as a new perspective on the management in general. Here is what else Chris said about tinyPM:

How is tinyPM helping you being more agile?

The taskboard is probably the most valuable as it’s a great way to visualise outstanding work.  The dashboard is probably next for us as it gives a good indication of progress overall.

What kind of projects do you use tinyPM for?

Web projects – currently the size of the projects has been relatively small, but TinyPM has been really handy for keeping track of requirements/time spent as well as introducing the team to agile methods that we can hopefully apply on larger projects in the future.

What would you change or add in tinyPM?

A hosted version!

Well, as for the latter we actually offer a hosted tinyPM, but we’re working on a tinyPM 3.0 which will start as a full SaaS solution from the very beginning. Those of you running tinyPM on your local servers don’t need to be worried. There will be still a downloadable version available.

Thank you once again for participating in the survey. If you didn’t have luck this time, soon there will be another chance. Stay tuned!

What the Story Card Color is Telling You?

October 19th, 2011 by Marcin Niebudek

We always thought about color-coding story cards as a very good way to indicate different types of user stories. The most popular was of course to use the red color to indicate bugs. But also green played well for indicating some general ideas to verify or think about (expressed in terms of a user story on the board).

Lately we’ve received a graph from Tatham Oddie, one of tinyPM users, who thought that we may find it interesting to see how they used card colors in tinyPM. A few minutes later I was asking Tatham if we may share it with others and here it is.

And this is what Tatham says about it:

“We’re building a guided case management system. The team in the organisation who determine all the guidance are the Practice Development Centre, or PDC. Early in a user story’s lifecycle, it’ll bounce back and forth between our PO and the PDC team. PDC don’t have access to tinyPM, but the PO uses colours to track which stories are dependent upon PDC outcomes.

Once the PO and PDC are both happy, it progresses to blue which indicates that the user story is of sufficient stability for the dev team to raise any of our own queries, then size it.”

So what they actually did is that they create a color-coded workflow bringing user story to a READY state. And how do you use card colors on your board (not necessarily in tinyPM)?

AgileByExample 2011 – Books Given Away

September 20th, 2011 by Marcin Niebudek

We just came from AgileByExample conference which we sponsored and co-organized in Warsaw last week. As the organizer we don’t want to rate it, but from the feedback we’ve received from the audience and speakers it was a success and a good start a new repeating agile event in Poland.

tinyPM gave out a few prizes at the end of the second day (including a very interesting book by Jutta Eckstein about working with dispersed agile teams). And we gonna do that again :-) just this week as tomorrow we are heading to Kiev for AgileEE. See you there!


What Criteria Do You Use When Choosing Agile Tool?

August 29th, 2011 by Marcin Niebudek

This question has been asked today on LinkedIn Q&A. I wanted to post an answer there in the first moment, but then I though that those Q&A’s tend to fade out very quickly and maybe answer to that question deserves some more attention.

Different criteria in different contexts

Well, the question was asked from a perspective of a tools reviewer. This in fact makes it more interesting. Normally I would say just choose the criteria that match your team or organization needs. But here its different.

What one should do to review a few dozens of tools on the market? Is it possible having a “generic” reader/tool user in mind? Is there someone like “generic” tool user seeking for an advice in choosing the agile tool? Sure there isn’t.

There are many agile flavors. Even if we choose to call some of them “methods” which would suggest they consist of more strict rules to follow – they don’t. Teams or the whole organizations choose different practices to be applied. Even same practices or ideas are applied in different ways.

Tools usually will do better in some aspects and stay behind in others. This is natural effect of different influences and experience their creators have. So each of those organizations needs a different set of criteria.

So let’s turn things upside down

What if the reviewer tried something different and yet something we perfectly know (at least in agile world)? How about taking the tool under the review and finding a set of user personas that this tool is going to be best for? How about creating something similar to a persona but for the organization? Maybe some kind of imaginary company profile that the tool would fit the most.

What goals the tool will satisfy? Who may have such goals (in a software company for instance)?

Maybe it will be Jack the Geeky Developer who works in a 5 people team and have a remote Product Owner. Jack works on 3 projects at the same time (two of them are in the maintenance mode) and wants his current assignments and commitments to be easily accessible for him. He may be able to switch between them easily and the Tool X will do the best for him as it’s good in organizing the work in many projects.

The Tool will be also good for Alice – the Scrum Master of a few teams in her organization. Alice shares her time between those teams and needs to be up to date with each one instantly. Which would be satisfied by features A and B.

But Bob, who likes extensive reports full of charts and KPIs, may be disappointed with the Tool X which provides only basic data exports. There are more data hidden in the Tool’s API but Bob will not even care to dig into this. He has simply no time for that.

Is the the organization where Jack, Alice and Bob work similar to yours? Then this may be a good tool for you, but only when you are able to convince Bob that the information he will get is enough to run the company.

I’d love to see some reviews like this. I think it might do more good than assigning some points in various categories and publishing the overall score. This kind of criteria based evaluation can be done only internally where there is one organization and many tools.

But when you are on the other side and try to review the tool (of any kind), then no set of criteria will ever be relevant to a particular reader (or at least to just a few of them). On the other hand reader may see herself in one of the personas you will try to describe. If so, then maybe the tool is right for her. Otherwise she will know instantly that this is not her Bob and Alice.

How does that sound to you? Wouldn’t that help you more in choosing the tool (or at least choosing it for further evaluation)? Just an idea…

tinyPM v2.6 Released

August 25th, 2011 by Marcin Niebudek

We are happy to announce that tinyPM 2.6 is available for download! This version brings highly requested taskboard customization along with largest REST API improvements and extensions since its release with v2.0

tinyPM REST API

Taskboard Customization

We’ve been writing about the taskboard customization lately, so you can watch a short video there and see how it looks like. We’ve also added the ability to hide done stories on taskboard. This will help you work with longer iterations.

If you are shifting from strictly iterative development into more Kanban-like one, then you may extend the default tinyPM taksboard by adding additional states to your flow and treat iterations more like releases.

This means you can create 1-2 months long iteration, turn on hiding done stories and work by continuously adding stories to that iteration. Doing so will let you remove short artificial time boxes and still use some higher level planning.

REST API Improvements

tinyPM 2.6 brings also many API changes request on our feedback forum and in e-mails from our users. You will find for example:

  • new resources to work with comments
  • new resources to work with timesheet data
  • additional resources for accessing and creating stories
  • extended data in already existing resources

All changes has already been updated in API documentation. Most of them should not break any existing applications (unless you parse the data in some custom way). The only change that is not compatible with old versions is task state data. This is due to taskboard customization and the fact that there are no more hard coded task states in tinyPM. You will now need to obtain available states from project resource.

As always the full list of changes is available in our documentation. Download new tinyPM today!

Taskboard Customization in Upcoming tinyPM 2.6

July 29th, 2011 by Marcin Niebudek

The awaited tinyPM 2.6 is almost ready and today we’re showing you the preview video with taskboard customization that will be available in this release.

You will be able to add columns to represent more granular states for tasks that are in progress. You will be also able to rename all existing columns. This will be of course done per project, so you can adjust each project taskboard separately.

Finally when removing taskboard column, all task that are currently in this column (in all iterations across the project) will be automatically moved to the previous state.

User stories will still have three states -- pending, in progress and completed. First task state will map to pending status, all task states in the middle will be treated as work in progress higher in the hierarchy and the last task state will be treated as completed status.

This is the first step of introducing more Kanban features in tinyPM. How do you like it?

Dude Where Is My Feature?

July 19th, 2011 by Marcin Niebudek

Looks like we will start a new series because today again I would like to write about something that relates to the question received from one of our users. Let’s take a look at story acceptance process.

So there comes the day when you demo your product and a product owner shall accept stories after just closing iteration. We’ve implemented a quite simple and intuitive way of accepting or rejecting stories in tinyPM.

Basically, as a Product Owner, you can do two things for each story that has all its tasks completed:

  1. Accept the story – which simply marks it as accepted.
  2. Reject the story – which will also mark the story as rejected, but in addition to that you need to provide a reason for rejecting the story. This description will become a new task within the rejected story.

And here the story begins… What should happen now with such a story? Due to added task the rejected story goes back to “in progress” state because not all tasks has been completed. In other words, by rejecting the story we add more work to be done to finish story correctly.

But it’s the end of the sprint. This leaves basically two choices (well maybe three but the 3rd one is a bit unlikely):

  1. You move the whole story to the next iteration. Yes, sorry, it’s not done done and you loose velocity.
  2. You leave the story accepted, create another story like “Minor/non-blocking bugs from previous iteration” and move the task there. This way the story will have all tasks finished again and it’s possible to leave it accepted where it is now (you may add a comment to the story to give at least some trace of the bug there).

But even if the 2nd solution may sound tempting, I would call it a project smell in the long run because you may find yourself moving many tasks this way. It will result in violating Definition of Done and cheating on velocity which will most likely stay intact. I wrote about it once in “Shall I Split My Stories? Yes… I Mean No!”

I’ve mentioned the 3rd option, so here it is (but rather unlikely).  If it’s really a minor bug and you have still some time in the iteration, you may fix it (for example the same day) and still get the story accepted.

I would rather opt for the 1st solution as it may actually reveal the root problem if you will notice loosing velocity in such a way a few times more. Maybe you overcommit in the first place and then need to cut corners. Or maybe you should work on improving communication with your PO during the sprint to learn what may be wrong with your stories earlier. This way when it comes to the final demo most of the stories will get accepted as they meet the PO’s expectations better.

And which way do you choose most of the time?

What Time Is It In Your Project?

July 4th, 2011 by Marcin Niebudek

One of our Clients brought our attention to one of the problems with time zones. You may not have noticed that in you tinyPM instance especially if you host tinyPM on your own. But they were using our hosted version where this problem turned out to be easier to spot.

So think for a second what does it mean when you say that your iteration start on Monday, July 4th?

Well at the first sight it may appear to be a strange question… at least if your whole team is co-located. But what if part of your team sits in London, part in New York and the rest in Sydney? What does the 4th of July means to you then?

Let’s assume we’re in London. In a face to face conversation you would probably mean July 4th around 8 am (which, in other words, means the start of your working day). Ok this will remain the 4th of July for New York (but around 3 am) and also 4th of July in Sydney (3 pm).

However when you use electronic tools and you enter dates without specifying time, this usually means 4th of July at midnight. Instantly your team members from New York will see it as 3rd of July (7 pm).

Of course handling different time zones is not a problem for the tool itself. The question is more general. How do you define your project dates in highly distributed environment? We would choose a single time zone for the project to be used for raw dates so that everybody knows that what we mean when we say July 4th, 2011.

This is also what we’re introducing in tinyPM 2.5.6. You may now define a project time zone. It will be presented next to all date fields which do not require time (like iteration start dates and release dates).

As usually you may find the list of all changes in tinyPM 2.5.6 at:
http://documentation.tinypm.com/display/DOC/Change+log