There is a story card on our wall estimated to 8 points. It’s so easy to tear it down and put two new 3- and 5-point cards instead of that big one. Cool, we can even move one of them to the next sprint. No, no, no…

But wait there is another story in our backlog. This one is big… No problem – lets split it into smaller functionalities. Yes… and yes!

So what’s the point? Is there a problem in splitting stories anyway? The short answer is “yes and no”. It’s because the problem lies not in splitting stories, but in the moment when we do it. There are usually to points in time when we think about dividing stories into smaller parts: release/sprint planning and the end of current sprint.

Plannig

This is the moment when we think about stories before we start implementing them. We choose what is possible to do within the planned period of time. We gather detailed information about stories that should be implemented first. This is the moment when we try to plan the work that fits into our capacity usually driven by some observations of our recent velocity and other factors.

At this point we may find some stories to be too big to fit into the sprint, but we realize that we can split them into smaller independent parts that are still able to bring value to our clients. We choose more valuable stories and leave the other for a better time or even get rid of them. This is where I say YES to splitting stories.

End of sprint

Next time we tend to think about splitting stories at the end of our sprints. This is caused by one reason – we just can’t finish the story by the end of the sprint. We thought we will, but (again) it wast one story too much. Actually we have it almost done. And this “almost done” tempts us to split the story, leave the finished part in the current sprint while moving just the unfinished chunk into the next timebox. Hurray! Our velocity, charts and metrics have been saved once again!

This is the moment what I say NO to splitting stories. Story should be either fully completed or moved to next sprint. And yes, velocity should drop this time. This is the only way to spot the problem in the long term. Ok, it’s not a problem when it happens once. But if we will break down stories at the end of the sprint regularly to keep our velocity untouched then we may miss the root problem (there will be no sign of it, except for a not so happy face of our PM/SM who needed to tell our client about yet another unfinished story).

The root problem of unfinished stories may be:

• (most likely) wishful thinking – we keep thinking that we can do more this time and load our sprints with too much stories
• too short iterations – the amount of features for the increment is good (less of them would not give any usable product) but we try to implement them in to short iterations, so maybe one week is to little and we should switch to two weeks
• inaccurate estimations – if we have lots of unfinished stories every sprint this means that those stories tend to take more time than we thought and if it keeps happening then we should rather reestimate some of them and try better understand what they are about

So think about when you usually split your stories? Maybe it’s time to look deeper into your process.

We’ve just released tinyPM v2.3 which brings completely redesigned timesheet. New timesheet allows the team to look at time spent and time left estimated from the iteration perspective. It also provides the insight into all team members activity during the iteration which is more transparent than it was in the previous tinyPM versions. You can now easily see when the tasks were actually active during the iteration and who was working on them.

Filtering by user and iteration along with the time spent export to CSV format gives everybody the ability to create further reports using the data that already exits in tinyPM.

But wait… there is more. What else tinyPM v2.3 brings you this time?

• time left can be directly edited on task cards (taskboard view)
• improved tasks burndowns
• foldable iterations on backlog view
• user can choose not to receive e-mail notifications about actions he triggers
• user own actions excluded from history RSS feed (now he sees what other teammates were doing)
• user can delete his own comments
• fixed drag and drop issues on backlog
• fixed default tasks validation which caused errors when creating stories
• improved help messages when getting started with tinyPM

If you want to see all this in action, take a look at our DEMO:

http://demo.tinypm.com

Once again we are going to Kiev for Agile Eastern Europe Conference which will run this Autumn (8-9th October). Last edition was a great event and we expect this year to be even better. It’s enough to look at the speakers lineup, to be sure that Agile Eastern Europe once again will become a really international event:

• Mary POPPENDIECK (USA)
• Henrik KNIBERG (Sweden)
• Danko KOVATCH (Israel)
• Marc LOFFLER (Germany)
• Paul KLIPP (Poland)
• Anda ABRAMOVICI & Sudhindra RAO (USA)
• Robert DEMPSEY (USA)
• Vasco DUARTE (Finland)
• J.B. (Joe) RAINSBERGER (Canada)
• Mack ADAMS (Canada/France)
• Robin DYMOND (Canada/USA)
• Yves HANOULLE (Belgium/France)
• Monika KONIECZNY (Poland)
• Andrea HECK & Tibor VIDA (Germany & Hungary)
• Allan KELLY (UK)
• Dr. Johannes MAINUSCH (Germany)
• Sergey DMITRIEV (Norway)
• Piotr ZOLNIEREK (Poland)
• Sergei ANDRZEEVSKI (Russian Federation)
• Andrea PROVAGLIO (Italy)
• Pawel LIPINSKI (Poland)
• Nikita FILLIPOV (Russian Federation)
• Pavel GABRIEL (Belarus)
• Artem SERDYUK (Ukraine)
• Mikalai ALIMENKAU (Ukraine)
• Timofey YEVGRASHYN (Ukraine)
• Michael NORTON (USA)
• Pawel BRODZINSKI (Poland)
• Francois BACHMANN (Switzerland)
• Jurgen APPELO (Netherlands)
• Zsolt ZSUFFA (Hungary)
• Gwyn MORFEY & Laurie YOUNG (UK)

We are proud to be once again to support the conference as a Bronze Sponsor, so if you use tinyPM, think about using it, want to talk about the tool, it’s capabilities and your need, then Kiev will definitely be a place where you can push us to the wall and ask all the hard questions.

If you haven’t decided yet to come, go on and REGISTER now!

tinyPM provides at the moment several ways to track project’s progress using different types of charts:

• project scope burndown chart (3 types)
• project budget tracking chart
• iteration scope burndown chart (based on story estimates)
• iteration scope burndown chart (based on task estimates)
• iteration scope burndown chart (based on reported time left on tasks)

Those charts are driven by four types of data available in tinyPM:

• effort, on the user story
• effort, on the task
• time spent, on the timesheet activity
• time left, on the timesheet activity

All those elements are optional to use and every user can choose for herself if she wants to use only some of them or all. You will find a cheat sheet with a summary on all tinyPM charts in our documentation at:

http://documentation.tinypm.com/display/DOC/Charts

Entering each one of those elements provides different level of insight into project state, so let’s have a look at what can we see in tinyPM by providing each of that data.

User story estimated effort

You can enter estimated effort for every user story. This is the most important and most commonly used number in tinyPM. Story estimates allow planning, are used to calculate average velocity that tinyPM suggests as capacity for newly created iterations (planned velocity field). Finally story points drive all project scope charts, iteration burndown based on user stories. Story points are also used for drawing scope series on budget tracking chart.

We’ve been posting some information about types of project scope charts available in tinyPM in the article “Burning Down, Climbing Up“, but let’s recap some key points from the tinyPM user’s perspective.

Project scope chart based on total effort. This chart start with the value of total estimated effort entered for all stories in the backlog. Every completed story (all tasks completed) burns this chart down (blue line). This type of chart contains also the green line calculated from planned velocity entered for each iteration. This type of chart never goes up.

Project scope chart based on initial effort. This chart starts with the sum of estimated effort entered for stories created before any iteration is created. For each iteration we calculate currently estimated effort for all user stories. This means that if any story is removed during some iteration then the chart will fall down faster, but if some stories are created during such iteration (after the start of the project) then the chart may even go up (if stories added are worth more points than stories completed during that iteration). Effort completed for each iteration on this type of chart is calculated using the following formula:

effort left (real) for iteration N = estimated effort of stories created until iteration N – effort completed by iteration N

Project burnup chart. This type of chart is the easiest one to use as it starts with zero and every story completed during each iteration pulls the effort completed line (blue one) up by the number of story estimated effort. All changes in total scope of project (stories added or removed during project) are represented by the additional series of total scope (gray line). If all stories are created before initial planning of iterations then the gray line goes up at the beginning and and stays constant during all iterations. However if any user story is added later in the project (and has estimated effort defined) then this line goes up and the whole point is that both blue and gray lines meet at the top right corner of the chart at the end of the project.

Iteration burndown (“User stories”). This chart is similar to the project burndown based on total effort. It starts with the total estimated effort for all stories added to the iteration. On the day when user story is completed (all it’s tasks are completed), the chart is burned down. This means that this chart works well for projects where stories are relatively small within the iteration and are quickly completed. Otherwise this chart may stay unchanged until the very end of the iteration when all the stories are finally completed within one or two days.

Effort on the task

You don’t need the tasks estimation if you have small stories that can be completed within one or two days. In this case estimates on stories and iteration burndown based on those estimates are totally enough to track project and iteration progress with a proper level of detail.

However if you stories get bigger and you like to define more tasks for each story, then you may want to start tracking tasks instead of stories. In this case tasks can use different scale of estimates than stories (defined in project settings page). This gives a possibility to:

• estimate tasks using relative scale like story points
• estimate tasks using time units

If you only want to escape the trap of big stories completed mostly at the end of iteration then the only thing you need is to have more detailed tasks in those stories. tinyPM is able to present two types of iteration burndown chart based on tasks.

Iteration burndown (“Tasks”). This chart may work with tasks without any estimates. If tasks estimation is turned off then all tasks will be treated as even (assuming they are small enough to be completed within a day). They burn down they chart when they are completed. Additionally each task in progress is presented as the yellow area on the chart so that it’s possible to see if a lot of work is in progress but not completed. If the tasks are estimated, then the estimates are used to calculate the burn rates on the chart and bigger tasks burn it quicker than the small ones.

Iteration burndown (“Effort left”). This chart (apart of task estimates) requires entering time left on tinyPM’s timesheet. However if you don’t do that and provide only estimates for tasks you will notice that it will look like the one based on “Tasks”.

Time left on the timesheet activity

Time left comes from Scrum methodology when it’s declared every day for each tasks in Sprint. Iteration burndown (“Effort left”) starts with total estimated effort of tasks. Thats why, if you plan to use time left from timesheet, then task estimations should be also done using time units. After that, for each iteration day, all time left values are added up to calculate total time left to complete iteration.

This type of chart may go up if some day during the iteration we find out something that makes completing the task impossible withing the initially estimated time. At that point we enter higher value of time left for such task in the timesheet. So this chart to work properly requires both – task estimation and timesheet entries with time left for those tasks.

Time spent on the timesheet activity

Time spent entered in the tinyPM’s timesheet is used only on the budget tracking chart. Also the story estimated effort is used in this type of chart to calculate the scope line (blue one). Total effort entered for all stories becomes 100% of scope on this chart, while budget (in man-hours) entered for project (on project settings form) is used as 100% of budget (red line).

Each story completed burns down the scope line while, each hour entered as time spent (on timesheet) burns down budget line. More on budget tracking idea you can read in the article “We’re in the Right Truck!“.

Not so long ago I’ve been writing about first edition of Agile Central Europe and now there are only three weeks left to another very promising agile event in our region – OpenAgile Romania.

The conference has a very interesting speakers lineup and along with AgileCE and upcoming Agile Easter Europe makes a great set of affordable and very high quality agile events in the Central/Eastern Europe. So make sure you won’t miss it!

tinyPM Team is also proud to be able to support this event as a Bronze sponsor. Early bird registration ends on May 5th, so register and visit Bucharest this spring.

We’ve just released tinyPM v2.2.2 which makes user accounts more personal. Now you can add a profile photo, contact information and personal description. This is most important when working with distributed teams. Now your teammates from other locations will be able to know better real people behind user initials from the task cards on their taskboards.

tinyPM 2.2.2 comes also with improved connector for JIRA which now supports connecting to JIRA instances using self-signed SSL certificates. Among other fixes delivered with this release you will find:

• improved story status presentation (combined tasks status and acceptance status into one indicator)
• fixed tabindex on userstory and task forms
• fixed default task for newly created projects
• fixed problem with backlog rendering when user has no permissions to edit stories
• fixed calculating task progress status by date (tasks burndown refreshing problem)

Last but not least starting from this release we provide standalone tinyPM version for Linux and OpenSolaris platforms. You can download new tinypm-2.2.2-install.jar installer from:

http://www.tinypm.com/download

AgileCE 2010 is over. It was a great organized, unique in terms of scale and speakers agile event in Poland. All talks were recorded and will be probably published at the conference website, but here are some notes from the lectures I’ve attended and find interesting to share just right now.

The Talks

Jens Korte – ScrumFluenca

Jens presented part of his great work on documenting sources, influences and theories that led to forming Scrum method and keep influencing all kinds of agile movements. Jens made a very interesting chart which you will find at http://www.agilefluenca.org and I strongly recommend you to take a look at it. This is a really good piece of work, that I hope Jens will continue to update.

Monika Konieczny – How to cope with communication problems in an agile project?

Monika presented an idea of using simulation games to improve communicating some ideas within teams and mentioned also an interesting theory called “The Fun Theory” which I like very much (see http://www.thefuntheory.com). All that started with a very funny game of backing cake by an IT team You should definitely watch it when the video will be available at AgileCE site.

What I missed in Monika’s talk, were 2-3 cases or real projects examples of games that solved some particular problems which would turn the talk from theoretical to more practical.

Zuzana Sochova – Company Culture as the Key Agile Milestone

Zuzana presented some of the results of her MBA research on organizational culture influence on successful agile adoption. Zuzana already posted slides from her talk at http://www.slideshare.net/zuzuzka/company-culture-as-the-key-agile-milestone. Also the survey results are available at Zuzana’s blog (http://soch.cz/AgileSurvey.pdf)

Paweł Lipiński – Being an agile nearshore team

This was the best Pawel’s presentation I’ve seen so far. It’s because his talk was based purely on his experience from running his own company Pragmatists and building there a really agile environment. What we miss the most on agile conferences are the real cases and examples agile / xp implementations instead of all that couching / consulting theory many time full of wishful thinking. This presentation was real from the start to the very end.

There are also a few interesting ideas that I’ve noted out from Pawel’s talk:

• using a single user in your version control system along with pair programming to eliminate blaming and empower collective code ownership
• customer clicks through the application during the demo session – this makes him focused on what he actually accepts
• often pair switching when pair programming prevents team members from achieving small small goals and successes (like finishing a single task) and does not work well – switch pairs after the task is done
• customer not paying for not accepted work – encouraging time and material way of work by sharing a risk

Paweł Brodziński – The Kanban Story

Same as with Paweł Lipiński talk, this one also contained thoughts and motivation from the real life example of implementing Kanban. A few thoughts I’ve noted out:

• Kanban without strong engineering practices produces garbage (garbage in – garbage out)
• change of the Kanban board triggered by the team member that holds a sticky note and does not know where to put it

We also continued the talk about Kanban on the open session during the lunch break. You can read the full story about this kanban implementation at Pawel’s blog:
http://blog.brodzinski.com/2009/10/kanban-story.html

Gwyn Morfey & Laurie Young – The Sword and Other Tales

This was a great and entertaining closing of the AgileCE. The talk’s (or shall I say performance) main theme was how to focus on quickly and without unnecessary ceremony solving all kinds of  issues that an agile team may face. Gwyn and Laurie talked about how to change and improve the solutions to make them stick. Definitely a video worth watching when it will be posted at AgileCE website (you will find out about sword of integration, stealthholders, heat-seeking actions and more).

Short Retrospection

So what went well?

• The venue was great and perfectly prepared for this kind of event
• Good set of talks with interesting and original content that we couldn’t hear before in Poland / Central Europe
• Very well organized (kudos to Paul Klipp and his team!)

What could be done better?

• Open Space sessions during the event of this size (150 – 200 people) should get their own piece of time line during the tracks instead of competing with the talks. The most talks has been scheduled during the lunch break as the most people did not wanted to choose between talks and open space sessions.
• Marketing should have been started much earlier. I had an impression that many people did not had a chance to come to AgileCE because they just learned about the event to late.
• The schedule should be posted earlier next time (even if it about to change slightly later on) because many people decide about attending mostly by looking at conference talks and schedule.

Overall the event was great and as tinyPM team we’re proud we could support it as the Bronze Sponsors. Now we’re waiting for a next great event in Kiev (AgileEE) and definitely are waiting for a next AgileCE in 2011.

We’ve just release tinyPM 2.2.1 which adds new tinyPM connector for UserVoice. This plugin allows you to integrate your UserVoice forum with tinyPM sandbox and automatically import posted suggestions. When you’re ready you may convert them into stories.

Right now connector does not update suggestion statuses back in UserVoice forum, but we hope to handle that soon. So let’s take a look at how to configure new connector in tinyPM.

Connecting to your UserVoice forum with tinyPM

First thing you need to find is your forum URL. So simply go to your UserVoice page and go into your forum (if you have more of them). What you get in the address bar is the required forum URL.

After that choose Connector for UserVoice in tinyPM data source settings (projects list -> ) and set your forum URL.

That’s all you have to define. Now tinyPM will pool all new suggestions whenever they are posted to your UserVoice forum.

What else did we add in tinyPM 2.2.1?

• defining more than one default task for your stories
• defining estimated “time left” in the timesheet
• Scrum-like iteration burndown chart based on “time left”
• deleting more stories at once on backlog (new menu “Actions” for each iteration)
• iterations are now always ordered by start and end dates
• fixed “close iteration” problem when iteration positions are messed up
• default iteration name pattern is now configurable in project settings
• iteration number is editable again to be able to make “Iteration 0″ the first one and keep proper naming of subsequent iterations
• added “Actions” menu for stories and sandbox items
• editable user initials (no need to hack user names anymore)

We hope you will find all those changes helpful.

So you know already that tinyPM 2.2 have Sandbox with connectors that allow you to import items, issues, messages and ideas from different places. For a good start we equipped tinyPM with two connectors. One for getting issues from JIRA and one for importing e-mail messages sent to any POP3 mailbox. Now let’s have a look at how to configure them and use to populate your new Sandbox.

Connecting to JIRA

tinyPM uses JIRA API to import issues, but the API requires you to create a filter. So the first thing you need to do is to create one in your JIRA.

tinyPM will monitor any defined data source periodically so any newly reported issue. Data source are defined separately for each tinyPM project, so you will probably filter only issues from a particular project in JIRA too. To do that go to issue navigator and set filter for the issues that you want to have in tinyPM. Let’s say we want to import all open issues from project DEMO.

After filtering issues JIRA gives you the option to save the current filter. This is exactly what you want to do. After saving the filter under any selected name the important thing to get from JIRA is the requestId=10010 parameter which is your filter ID.

Now it’s time to create a data source in tinyPM. Go to projects and click on project data sources icon . After that select “Connector for JIRA” and enter your JIRA URL, user name and password for the user that has access to JIRA and to created filter (unless you shared the filter with all JIRA users).

That’s it! After few minutes you should see the currently open issues from JIRA imported into your sandbox. New onse will get there as soon as they are created in JIRA. You can create stories based on the imported issues or you can reject them them without flooding your backlog. They will get a proper comment in JIRA.

Connecting to POP3 mailbox

You can connect to any POP3 mailbox and tinyPM will import all e-mail messages sent to that address into the Sandbox. How can that be valuable? You can create a special sandbox like demo-stories@example.com where you can sent any of your ideas which you may later on upgrade to a user story in tinyPM. You clients can sent any project suggestion in a simple and convenient way directly from they favorite e-mail clients.

To setup POP3 data source simply configure the mailbox just like you do that in your e-mail client software. After that tinyPM will pool that mailbox every few minutes looking for new e-mails.

You can limit the list of users that are allowed to send e-mails that will be imported by tinyPM using the allowedSenders property. This property accepts comma separated list of addresses and also accepts simple * wildcard in any part of the address. On the picture above we’ve limited allowed senders to the e-mail addresses in the domain example.com

That’s all you need to do to user the power of new tinyPM sandbox. But stay tuned as new cool connectors are coming soon! If you have any suggestions for the connectors that we should provide next please don’t hesitate to post them on http://feedback.tinypm.com

We’ve just released the new tinyPM 2.2 version which comes with cool new features. This version introduces tinyPM plugins for new product management section called Sandbox and ships with two initial integrations for JIRA and POP3 mailboxes.

What’s new in tinyPM 2.2:

• Sandbox with connectors for JIRA and POP3 mailboxes (plugins)
• printing user story cards from taskboard
• tinyPM now speaks French

Sandbox will enable product owners to buffer all ideas, early concepts and bugs coming from all the places like bug trackers, support mailboxes, forums, company CRM systems and more. Those items, before they actually hit the product backlog can be gathered in the Sandbox which provides helpful states: NEW, UNDER REVIEW, ACCEPTED, IN PROGRESS, COMPLETED, REJECTED.

It is also a 1-click operation to create a user story from Sandbox item.

Connectors for JIRA and POP3 mailboxes provide you a way to easy get your bugs and ideas from specially created e-mail accounts directly into tinyPM, where they can be managed on their way to becoming a product features.

You can read more about configuring connectors in tinyPM in the upcoming post. In the meantime take a look at our demo at:

http://demo.tinypm.com

Or download your own tinyPM Community Edition for FREE at:

http://www.tinypm.com/download