Shall I split my stories? Yes… I mean No!
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.
PlannigThis 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 sprintNext 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.
Categories: Companies
tinyPM 2.3 Released
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:
Categories: Companies
tinyPM is going to AgileEE 2010!
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!
Categories: Companies
Getting the Most From tinyPM’s Project Tracking
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 effortYou 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.
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 activityTime 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 activityTime 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!“.
Categories: Companies