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
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.
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?
Marcin Floryan posted a short statement on Twitter lately that if someone else is assigning your tasks it is not Scrum. I fully agreed with that, but just a few days after a question from one of our users came and it mentioned people being “overplanned”. The question wasn’t directly connected with task assignments but the word “overplanned” brought my attention.
Should I be “overplanned” or maybe “overcommitted”? Ok… You already know my answer, but think about it for a second.
Probably the most common path for many teams is to convert a PM into Scrum Master or alike. PM is usually used to assigning tasks to the team members. This is what she was doing for a couple of years. No we want her to surrender. Wouldn’t you be scared?
So why should you actually be brave enough to let go and let the team decide?
You already let the them discuss, estimate and plan how much they can do in the next iteration, did you? They will know what to do.
You will tend to assign same people for same kinds of tasks, but it does not help them to get a big picture and learn.
Why not leave the decision until the very last moment? Maybe others will finish their work earlier and will be able to take the task before the person assigned to it in the first place.
From the iteration/sprint perspective delivering done stories is more important than not who is doing what. Let the team find a way to make it best they can.
It’s like with code ownership. There is no my code and your code (right?). Same with stories or tasks that lead to creating that code.
There is that little chance that I may know better than you what I’m most capable of doing so please let me decide what I’ll do next to deliver what we promised.
You have lots of other things to do. There is this guy (they call him a Product Owner) waiting to slip through your doors ;-). Focus on facilitating, impediments and communication.
But not to leave you with an impression that self commitment is so glorious there is at least one thing that you need to be aware of at the beginning.
People not used to making a commitment will usually tend to chose the easiest task. After some time you will find that there is someone doing the dirty and hard work while others live their fantastic lives with their easy pieces.
This may happen if your team members are left alone with the tasks they work on. You should look for this kind of “bad smell” during retrospectives. But still taking the control back is not your best option. Instead try:
directing your team towards swarming on a single story together
some mentoring or pairing (maybe some of the team members have a difficulty with the system, technology or anything else)
working on better knowledge exchange
So are you brave enough to let go and not to assign the tasks to your team?
BTW. In tinyPM when you grab a task from pending state, it instantly becomes yours. This is a lot easier that to assign a task to somebody else (you need to go and edit the task). Now you know why :-)
The image for this post comes from a great site Pictofigo
We offen get this qustion, so it may be a good idea to quickly answer it here as there are at least 3 different approaches possible.
Task in the original story
You can put a bug as a task in the original story. We use this approach when bug is found within the same iteration where the story is developed. We simply add a task and fix it in the same iteration. Bug found in the iteration must be fixed in the same iteration as the definition of done for stories contains “no known bugs”.
Separate story card
You can put a bug as as a separate story (usually as a red card). We do it when bug is found later, after the iteration where the original story was completed or if the found bug is more general and does not belong to any particular story.
Sometimes we create just a single aggregate story like “Bugfixing” and place all production bugs there as task. If the bug is serious and requires some more effort then usually has it’s own story with more task that need to be done in order to fix the bug. Bug stories are estimated as “0″ which means they have to be done but do not add up for velocity (so are treated as debt).
To estimate bugs or not is a whole different story, but we personally do not estimate them.
Finally you may use tinyPM’s sandbox as a place to gather bugs. There you can first check if they really are bugs or investigate them further before they will become stories. Some of them will be rejected and will never reach your backlog, some other will become stories.
Sandbox also allows connecting with JIRA bugtracker, so if you need a fully featured bugtracker and your bug tracking process is more complicated then sandbox connectors may be the way to go. This way you will keep the bugs in the external system and buffer them through sandbox in tinyPM.
Most of the time we use a mix of tasks and story cards while using sandbox as a buffer for ideas from our UserVoice forum.
I think tasks estimation and tracking progress based on story task estimates almost always leads to tasks becoming pseudo user stories within large and overestimated real stories.
When estimating stories we encourage developers to use points and to show only relative size within the whole set of stories. I think it’s much harder to do with specific, usually technical tasks – you start judging between activities of different type, for example implementing some component and designing user interface. In other hand estimating tasks quickly falls back into estimating in man-hours and might lead to tracking people instead of real progress.
Surprisingly when implementing our tool we found the feature request “Tasks estimation” to become the most wanted one, while we want to encourage our users to rather split stories into smaller functional parts and use tasks for stories as some kind of to do list for developers.
So what works for you? Why do you want or need to estimate tasks within stories?
For project tracking? You can track stories. The story is done when all tasks are done. When you have small stories you don’t need to wait long for visible effects even if you iteration is a month long. For making sprint/iteration burndowns? You can do it successfully with stories, but again you need them to be small functional parts not epics. If you have two big stories for one month then agreed, you burndown made of stories won’t look any helpful.
Or maybe somewhere down there you need those man-hours and strict task assignments for your manager/boss? Soare you brave enough not to do that :-)?