We were happy last year to take part in the first agile conference in the Central/Eastern Europe region in Kiev. That’s why we are even more excited that this year will bring two interesting agile events in this part of the world, with the first to be Agile Central Europe 2010 in Krakow.
As we’re always interested in supporting agile initiatives emerging in our region, we are happy to announce that tinyPM became a Bronze Sponsor of AgileCE.
The conference will take place in Krakow, Poland, 8-9th April 2010. By the February 15th you have a chance to get an early bird ticket for only 85 EUR for a 2 day conference.
During those 2 days you will be able to hear many interesting talks:
- Systemic Software Development for Agile Teams
- Distributed Agile in a Multicultural World
- Iteration Management - unclogging your development process
- The Sword And Other Tales
- The Agile Influencer’s Mantra
You can read more at the official conference site. So don’t wait!
REGISTER NOW and meet as in Krakow this spring.
February 2nd, 2010
tinyPM 2.1 introduced three types of project scope charts. We would like to write few words about differences, advantages and disadvantages of using each of them. We will use all three types of charts on the same project data, this way we can better compare the information that can be read from them.
Burndown chart
(with initial project estimation as a starting point)
As you can see, the project started with a backlog containing stories worth about 50 story points in total. When we use the initial estimation as a staring point we simply put the total backlog effort on the chart and each following iteration we mark how much effort there is still to be burned (blue line) and what is the expectation (the green line).
The green line never goes up because this would mean that we expect negative velocity. However the blue line may go up in one case, which is a feature creep. In other words, the line goes up when at some point of time (T10) more new stories get into our backlog than we can actually complete. This way at the end of the iteration we have more effort left than we had at the beginning.
So we can instantly see the feature creep effect using this type of burndown. But what can we say about our team’s activity between T10 and T14 or even T20? Did they do anything? Iterations where passing by (green line continuously heading down to the level zero) but we cannot see any significant move on the blue line. Does it mean that the team did not do anything, or that the backlog got as many user stories each iteration as we could complete. Actually it may be each one of those explanations. So the point is, that with this type of burndown we don’t know that exactly.
Finally when the green line hits the zero level we can see how late we are. In our scenario the project was supposed to be finished by the T14, but at that point the team was still missing over 30 points (new stories not included in the initial scope) and the distance kept growing.
You may say this project was in a deep trouble, but we intentionally chosen such data, because when everything goes well and the lines dance close to each other, there is nothing interesting to observe and the devil is in the details. What is so valuable about burndown charts, is that they can quickly warn us when some bad things start to happen. This project could have actually be rescued somewhere between those T10 and T14 points.
Advantages:
- simple to draw even on the white board
- can show a feature creep
- can show the point where the team loses the ability to actually complete the project
Disadvantages:
- doing nothing and doing only enough to balance a feature creep looks the same on this kind of chart
- cannot read the velocity out of this chart
- your backlog needs to be estimated at the beginning, otherwise you will soon cross the zero level (which will look odd)
What types of projects is it good for:
- good for projects with some initial vision represented in the backlog and estimated at the beginning (at least as the epic stories)
- good for projects with fixed-price contract as then we usually have an initial estimation and we want to watch it burned according to a planned velocity
Burndown chart
(with total estimated effort as a starting point)
This type of chart is recalculated each time it is viewed and the burndown always starts with the total currently estimated effort for all backlog items. So even if the project stars with about 50 story points, when we take a look at it after few iterations it shows current total which may be for example 80 points.
Here we can only observe the relationship between plan and execution. We assume that stories may be added to the backlog at any point of time. We may even start with few stories. Until the blue line stays under the green one, everything is fine. If we accept all those new stories (by simply extending the budget or by working based on T&M contract) then at the point T10 there is no trouble in our project - we’re still doing fine having velocity higher than expected.
At T14 we can see that the development stopped for some time. Probably at the point of T14 it reached zero (and maybe has been released), but later the velocity started to decrease (blue line above the green one).
On this type of chart both lines always go down. It does not tell anything about the feature creep in the project, but only about the changes in the team’s velocity.
The last observation that we can make with this chart is that at T29 planned effort reaches zero while there is still some real work to be done. This means that even with all those new stories we should have finished at that point and now we’re getting late.
Advantages:
- you may actually see the changes in team’s velocity in the project
- does not require any initial estimation, nor the fully populated backlog
Disadvantages:
- hard to maintain on the white board (requires recalculations for the past iterations)
- feature creep may not be seen
- treats all stories as “must haves”
What types of projects is it good for:
- as it does not require any initial estimation it’s best for some research projects or exploratory work where stories are invented based on the results from the recent iterations
Burnup chart
This type of chart actually climbs up. It also introduces the third series (gray line) which is the “current total effort”. It combines advantages from the both previous burndows and at the same time does not have their disadvantages.
We start the project with zero completed and planned effort. Total effort may start also with zero or it may start with some initial backlog stories estimation. The goal is to reach the “total” gray line with the blue one, so actually build all those planned features.
Here we can clearly see both - the velocity of our team (on the blue line) as well as any feature creep by looking at total effort line (gray one). If the gray line goes up, then stories are being added to the backlog (or re-estimated with some higher values) . When it goes down, it means the scope to reach gets smaller.
At the T10 we’re doing fine in terms of team’s velocity but at the same time our project scope gets larger. It’s time to decide if it’s something wrong or if we accept those new ideas. At T14 we’re done with some part of our product, and it looks like we’re are done just in time. However there is still lot to do (for example for release 2.0). T28 is the point when we actually planned to reach the goal (green line meets the gray one), but somewhere between T14 and T28 our team has lost it’s initial velocity and now we are still missing about 20 points (blue line still not there).
Advantages:
- shows most of the interesting patterns in all kinds of projects
- easy to maintain even on the white board
Disadvantages:
- none that we know of unless you find this chart being painted upside-down ;-)
What types of projects is it good for:
We hope that those examples will let you better choose the best type of chart for your project. We are waiting for you suggestions or any other ideas on how to visualize the project status even better.
November 10th, 2009
Recently we gathered some of our thoughts and practices about fixed price into a longer article which starts the series for agile techniques that work (don’t know yet how often we will be able to publish one of these).
We like to say that fixed price contracts are evil, but they are reality which many agile teams have to face. So what if we try to tame it instead of fighting against it?
The main point in the “Agile Team Meets a Fixed Price Contract” is that what actually bothers us in the iron triangle is not a fixed price nor the time but the scope which is defined upfront. So what actually the agile team needs to try, is to change the explicitly defined requirements into scope defined as the amount of work which has to be done.
In other words, exchange a “what” into “how much” value we need to deliver because “what” is about to change and we want that change to happen. How the company can execute this kind of contract using agile practices to achieve better results with lower risk?
Take a look at the full article in the white papers section:
http://www.tinypm.com/whitepapers
As always we are waiting for your comments. What works for us may not work for you, so we are always happy to hear about new ideas that worked in your context.
October 20th, 2009
Kelly Waters is running a pool on Recommended Agile Project Management Tool. We encourage you to take part in it and vote.
You will find the pool at:
http://www.agile-software-development.com/2009/09/agile-project-management-software.html
As we are doing all we can to provide you with the best and easiest to use agile tool on the planet, we’re always happy to hear from you. AND THAT INCLUDES ALSO COMMUNITY EDITION USERS :-) We’re open to any complaints you might have on every (even small) function you will find in tinPM.
So if you’re using tinePM, like it and want to support it in the pool then VOTE! We appreciate that!
It would be great to get a comprehensive poll of the marketplace and see what tools people recommend. So make sure your software of choice gets the votes it deserves (and hopefully tinyPM be the one you choose :-)!
October 2nd, 2009
I’m still about to write a roundup of AgileEE conference that we attended in Kiev few days ago, but just to warm you up I want to try a little quiz (somehow inspired by J. B. Rainsberger).
Take a look at the following quotes I’ve chosen from a single article:
- “For some reason what a software design is going to do is subjective to wide interpretation even after previous agreement. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery.”
- “[…] Every bit of code should be subjected to a simple visual scan by a second party who did not do the original code […]”
- “To give the contractor free rein between requirement definition and operation is inviting trouble.”
- “Test every logic path in the computer program at least once with some kind of numerical check.”
- “Without this simulation the project manager is at mercy of human judgment.”
- “If the computer program in question is being developed for the first time, arrange matters so that version finally delivered to the customer […] is actually the second version insofar as critical design/operations areas are concerned.”
- “Each and every worker must have an elemental understanding of the system.”
Do you see all the customer involvement, common vision/goal, code reviews, unit testing, prototypes that I see in this? So the question is where do those quotes come from :-) But don’t cheat :-) Make a wild guess.
I’ll post a response in the comments in few days if it’s needed (but I don’t think it will be necessary). So have fun while thinking about it for few minutes.
September 24th, 2009
Few days after the Agile Eastern Europe conference where tinyPM 2.0 has been available for the first time we’re releasing it officially.
We were writing already about some of the new features that are available in the v2.0 here:
But this does not complete the features list. Some of them improved slightly from beta version, some new were added, so finally tinyPM 2.0 contains:
- RESTlike API over HTTP
- Personal RSS feeds for history events (along with redesigned history view)
- Redesigned Backlog which now allows better prioritization and easier estimates editing
- Redesigned Taskboard so that it has less distracting UI and fits better big screens (or high resolutions)
- New Timesheet allowing to track real time spent on a task
- New type of burndown for tracking budget (we wrote about it some time ago in “We Are in the Right Truck!“)
All those high level items contain also many small improvements and features that we hope will support even better daily activities every team member needs to do in tinyPM. You can take a look at them before updating in our DEMO application by logging with users demo1 … demo4 (with the same password)
Along with tinyPM 2.0 we’re launching our documentation site where you will find all valuable information about tinyPM installation, configuration, usage patterns, all in one place.
http://documentation.tinypm.com
You can download new tinyPM at:
http://support.tinypm.com/downloads.jsf
The new version contains some configuration changes, so always remember to backup you data before updating and take a look at INSTALL.txt and UPDATE.txt notes. Those of you who will be updating tinyPM Standalone also make sure that you follow UPDATE.txt after running tinypm-2.0-install.exe
So enjoy the new version of the tool. We’re always happy to hear from you.
tinyPM Dev Team
September 23rd, 2009
We’ve revealed two more changes for tinyPM v2.0 which is coming in mid September. You can take a look at them, as well as earlier announced API and backlog changes, in our DEMO application:
http://demo.tinypm.com
Login with users demo1 … demo4 (with the same password)
Activity History RSS Feeds
Now you can stay up to date with all activities in your tinyPM by subscribing personal RSS feed with history events. This will be token based and will require turning on the RSS feature in the settings section (turned off by default).
Taskboard (redesigned)
We’ve redesigned the project taskboard view and enhanced it with some new options:
- it uses available space better
- allows to do more with taks by just dragging them around like on the real white board
- allows to quickly drag new top priority stories directly to the current iteration (good option if all other are done and there is some time before the end of iteration)
- provides sidebar with basic project information which can be hidden
- has to view types: all stories view and personal stories view (only stories that you work on or need to accept)
- sidebar provides a quick look at other stories (from other projects) that you’ve committed to
More to come…
Among other changes coming in tinyPM 2.0 you may also expect to find:
August 26th, 2009
I find SCRUM’s “sprint” a very intriguing name for an iteration. In the heart of agile development there is continuous delivery of a working software. To do that we time-box software development into iterations / sprints.
They have their rhythm and require different kind of discipline from our team. We become sprinters who continuously plan, test, implement, evolve architectures, deliver, improve the process, celebrate to finally be back in the starting blocks to launch another sprint. We do that iteration by iteration.
Can sprinter be a long distance runner?
A very common technique in agile projects is tracking team’s average velocity. It’s said that it should stabilize after few initial iterations on some level. This is also called finding a sustainable pace for a team, which in short means that our team members commit to just enough work to become productive without burning out to early at the same time.
I’m not going to convince you here why a sustainable pace is a good thing and why a tired developer is not going to be efficient and creative. It’s the opposite that always intrigues me in the name “sprint”.
When we sprint, we put all our energy to run a short distance (a single iteration) the best we can. However we plan our efforts differently when we are about to run a marathon of 20 iterations. So how long are we able to sprint and keep our average velocity constant?
Is there a point at which the team will start to loose it’s velocity? Well the answer might be that that’s where the sustainable pace comes to mind. We do not overcommit and we in fact stop sprinting at the maximum available velocity that we can achieve to sustain the pace.
Sustainable pace or sustainable undercommitment?
So how do we distinguish sustainable pace from sustainable undercommitment? Where is that point that we know we should not commit to more work as a team without being accused of just not being willing to do more while hiding behind a very nice term of “sustainable pace”?
My answer to that is great people, trust and transparency - all being the key parts of agile development. What is yours? How do you keep it at the level everybody accepts?
August 11th, 2009
tinyPM v2.0 is coming in September and as it will contain the biggest changes so far we decided to release a preview of two features in our DEMO.
http://demo.tinypm.com
Login with users demo1 … demo4 (with the same password)
tinyPM API over HTTP
The main theme of a new tinyPM version is opening our tool to external systems and integrations. As a first step we decided to provide a REST-like API over HTTP for all common tinyPM resources, which means we’ve tried to make the API follow the REST principles as much as we could. So if you were looking for ways to get tinyPM data out of the application and found the already existing “Export to CSV” option to be too limited, the API is for you.
We’ve setup the tinyPM DEMO application with the API enabled, so you check how it looks like right away. Along with a new API we’ve started a new site for tinyPM documentation which we will soon update with even more helpful resources. Take a look at:
http://documentation.tinypm.com/display/DOC/tinyPM+API
Backlog (redesigned)
We’ve redesigned the project backlog view and enhanced it with some new options:
- it uses available space better
- allows to prioritize stories within iterations/sprints with by simply dragging and dropping them
- allows to move stories between iterations and unplanned set of stories
- provides sidebar with basic project information which can be hidden to add even more space for main backlog contents
- has to view types: list and cards
New backlog is a first part of usability changes that we hope will make tinyPM even easier to use for a Product Owner and at the same time will make it yet more powerful. We’re also working on tuning the taskboard and dashboard views for the v2.0 release.
More to come…
Among other changes coming in tinyPM 2.0 you may also expect to find:
- personal RSS feeds with tinyPM activity history
- time and budget tracking (long awaited no 1 from our Feedback Forum)
- more e-mail notifications and enhancements
August 10th, 2009
Or yet another point of view on what to do with all those bugs in the backlog…
From time to time we observe a new discussion on whether we should put the bugs into our backlog or not. Opinions are diverse but I see one more aspect of that topic.
The idea behind the backlog is to have all items that we plan to ship for a product as some prioritized list. We leave the backlog in the hands of Product Owner and he decides what comes in and how important that thing is. the backlog forms the vision of what our product will be.
When asking ourselves about putting bugs/issues/tickets into backlog we usually look at it from the development team’s perspective. But lets take a look at what happens before product owner puts anything into the backlog.
We as a team perceive the backlog as the only source of the job to be done, but for Product Owner the backlog is the endpoint of the whole process of gathering ideas, requirements, issues from a lot of different sources. At the beginning of a new product development those sources might be:
- real users needs,
- client ideas and requirements,
- team’s own ideas about the product
As the development goes further bugs arise and at that point they are usually addressed during iterations. When our product is finally released and starts it’s own life then the Product Owner may (should?) use all sets of new sources to fill his backlog items list:
- feedback from the market (by e-mial, phone, through company’s help desk),
- bugs reported through the bug tracker directly or indirectly by users,
- sites that manage new ideas (like UserVoice or GetSatisfaction)
All those sources start producing new items that Product Owner is dealing with every day. They may be:
- relevant to the product vision or not,
- duplicates of other ideas that we already know from other sources,
- a part of some bigger requirement that will later on form a user story
Bugs, especially if we adopt the culture of avoiding them instead of waiting for their arrival, are only a small part of the list that Product Owner should think of when forming his backlog. Also each of the sources that Product Owner deals with have their own life cycles.
Bugs in particular might be:
- confirmed and fixed,
- rejected,
- postponed,
- merged with items from other sources to form stories.
Most companies adopting agile methods usually already use some bug tracking systems and have some flows for dealing with issues that are put in those systems.
When they start working the agile way, the first thought is to start putting user stories into the same bug tracker or convert their bug tacking system into agile management system by mapping user stories to tickets. Other think that now, as they’re becoming “agile”, they should stop using their bug tracker and find some “agile tool”. But after all they start thinking about where to put all those bugs and the only place they find is their new backlog.
I think that either way of thinking comes from the wrong assumptions that bugs can be treated as stories or handled the same way as new features development. Instead of that we should put our Product Owner, a “man of vision”, between the list of bugs (bug tracker) and the backlog.
If the Scrum Master or any other similar role (we’re not talking only about SCRUM) is the wall protecting the team and the process during the iteration, then the Product owner should become a wall protecting the product vision and the backlog. Does it mean that no bug will slip into the backlog? No… some of them will as they need to be addressed individually. But many of them will never reach the backlog in the original form.
I like the idealog concept that Mark Mansour described at:
http://stateofflux.com/2009/04/10/is-the-product-backlog-an-idealog
I think bugs should become at first a part of such list (idealog) next to the items from other sources connecting Product Owner with the real world. And only after becoming a part of such buffer they should pass through the first gate and become backlog items. Going from this point to the rich universe of tools you will start with idealog and the backlog (even if the tools to manage them are your white boards or some Spreadsheets). When it becomes insufficient you will end up with both: bug tracker and some agile management tool, as well as with all other tools that might help you gather the feedback about your product.
They all play a different role when we take a look at the product management part of the process.
July 16th, 2009
Previous Posts
Follow us on Twitter