Today the Product Owner of one of our teams popped by our desks to seek some advice on estimations. He seemed quite puzzled:
“For user story X, the team correctly identified that the work was at the database level. But when doing the actual estimation, they stepped back and left the expert database developer do the estimate. When the DB developer spoke out, I got some signals from the rest of the team that the estimation might have been inflated – still none of them said anything.”
I see 2 problems here:
1. Why isn’t the entire team estimating the user story *together*, even though it only involves DB work?
2. Why is the DB developer inflating the estimation?
In my experience, developers – as basic example – are not willing to estimate anything that isn’t related to their code, is a common pattern in teams starting Scrum. “How can I provide an accurate estimate in a field I am no expert in?” How have I solved it? Usually I try to insist on the fact that there are no *right* estimates and that the goal of all this is to generate a discussion that will help everyone to have a better idea of what the deliverables of a user story are. Estimates are not written in stone!
Inflating estimates is a little trickier… In this case, I know that the DB developer is actually part of another team which means he may already be overloaded with work from this other team. Inflating to avoid the burnout? Why not… How would I solve this? First thing that comes to my mind is to try to hire, which may not be solving the root cause. If that is not possible, I would suggest the team to inform themselves on the subject matter to become less dependent. Writing SQL queries is surely no rocket science when you can do .NET!
Questions to other Scrum or Agile practitioners: Did you encounter similar scenarios and how did you handle them? If not, how would you handle them if you did? Share your experience with us!
The Scrum literature often talks about *the* product backlog, generally implying that Scrum requires the team to have a unique Product Backlog, or that teams only work on 1 project at a time.
In our attempt to adopt Scrum in our organization, we found out that it was very challenging for us to maintain a unique Product Backlog. Not only are we working on a couple of projects simultaneously, but we are also responsible for maintaining the application. Imagine the headache for our Product Owner to prioritize a single Product Backlog containing all stories for all of our projects, bugs and smaller feature requests!
It’s only after several Sprints (and a flash of common sense) that we managed to solve this by having a Product Backlog for each running project. A picture is a worth a thousand words – so here is how things look like:
As you see, each project (A, B and C) has its own backlog. What does this mean concretely?
1. Each project has its own burndown and velocity.
2. The Product Owner can decide in the Sprint Planning on which project the accent should be put in the next Sprint, depending on changing priorities (Project A, Project B, urgent bug fixes on production sites etc.).
3. We go through each of the projects in order of priority during the Sprint Review.
There are definitely risks related to working on several projects during a Sprint: no common goal for the team, spreading resources puts projects in danger, breaking team cohesion etc. Being aware of these risks is important so you can act accordingly. I must say that so far, it has worked really well for us.
This post from the Project Shrink made me think. It made me think about the general relationship between project management in times of economic downturn and how project based organizations will react to this.
In my opinion, the current economic situation will accentuate the contrast between organizations that succeed late and those that fail early:
1. There will be organizations spending even more time trying to determine if a project is worth doing – that means these will probably do that even more, bet their year on a couple of key projects and see the benefits at a later stage.
2. There will be organizations spending even more time doing projects that will fail or succeed early – that means these organizations will spend more time doing projects rather than talking projects, bringing concrete results early.
The financial crisis means you have to start getting real. My hopes are that organizations will realize this too, and will spend more and more time doing projects.
What do you think the effects of this economic downturn on project management are/will be?
As usual a painless upgrade process. If you see anything weird happening on the blog, please drop me a note!
First look feedback: the new dashboard interface looks very nice with a handful of useful features (e.g. Quickpress, Quick Edit). Have you upgraded to 2.7? What are your impressions so far?
Wishing you a (belated) Happy New Year 2009!
