Saturday, February 12, 2011
Sunday, January 23, 2011
What else is wrong with Story Points as a time unit?
There is one another point against considering a story point as a certain period of time (e.g. half a day). It is difficult to use special planning cards for a planning session because their values are like 1, 2, 3, 5, 8, 13, 20, etc. but the time in other hand is linear. So the problem is what to do if we estimate that something should take 17 days?
The original post with comments
The original post with comments
Why Story Points should be abstract units?
Imagine that you assumed that 1 story point is about 4 ideal hours of work and you made all the estimations according to that assumption. When the sprint finished you divided a sum of story points of done stories by a number of spent hours and the result was that 1 story point is 6 hours. So how to proceed during the next sprint planning? If we assume that 1 story point is now 6 hours, we estimate stories in a different way than before. In other hand, keeping in mind that 1 story point is 4 hours, although we know that last sprint it was 6 hours is also confusing. In the described case 1 story point corresponds to some certain time, so it looses its real meaning.
Story points should be some abstract units expressing relations between stories in a way a team asses them. When they are abstract there is no other way to estimate a story than by comparing it to already estimated stories. Thanks to that, estimating is always the same, there is no confusion.
Story points should be some abstract units expressing relations between stories in a way a team asses them. When they are abstract there is no other way to estimate a story than by comparing it to already estimated stories. Thanks to that, estimating is always the same, there is no confusion.
Wednesday, January 19, 2011
PM Professional Programme Completed
Yesterday was the last day of the PM Professional Programme in which I participated. It was a great training, considering the content, trainers, arrangements and of course our group. Now it is time for PMI C-Level certification ;).
I come from and usually deal with the Agile approach so one could say that such a training is waste of time. Not at all! I've learned interesting tools which can be useful also in Agile projects. I understand better the relation between a project management and Scrum which is very often hot topic. I'm going to write a bit more about that in the next posts...
I come from and usually deal with the Agile approach so one could say that such a training is waste of time. Not at all! I've learned interesting tools which can be useful also in Agile projects. I understand better the relation between a project management and Scrum which is very often hot topic. I'm going to write a bit more about that in the next posts...
"Towards Agile Product and Portfolio Management"
Few months ago I was on a seminar about agile portfolio management. The presentation didn't really appeal to me, maybe because I expected something different, maybe because of my background, but I could see that the investigation of the subject required a lot of work. Later on I got an email from the authors saying that they published their book about their research. I didn't have time to even review it, but I'm quite sure that it is very interesting lecture. The title of the book is Towards Agile Product and Portfolio Management and you can read it under following link:
http://atman.agilefant.org
Sunday, November 28, 2010
WBS and Scrum
WBS is a great tool to give a thought, especially that recently several people asked me about it. There are several aspects which might be considered...
Some people things that WBS is something totally detached from Scrum. I don't agree with this. First of all if we would show a product backlog and a sprint backlog as a structure, we could consider it to be WBS. The main difference would be related to the fact that WBS must cover 100% of the work effort what means, that we at least have some placeholders for the work which is unknown at the moment. Regarding similarities, PMI Book explains that WBS decomposition for a deliverable or a subproject that will be accomplished far into the future may not be possible. In that case the team waits until they have more knowledge (Rolling Wave Planning) - sounds like Scrum to me:).
Recently my colleague asked an interesting question. He said that he already has WBS for his project but he would like to start following Scrum, he asked what he can do with it? It depends on the WBS which he has, but most probably with small modifications, WBS items could be used as themes, stories and tasks. In addition Scrum doesn't say that you can't have a detailed plan in the beginning, it just says that it might not make sense to have one and that it might be misleading. WBS items could be helpful during Sprint Planning meetings or calculating an initial team velocity and an initial release schedule.
It is also important to remember that WBS is not meant only for PM, but it is also a communication tool, shows a customer why a project is estimated for a certain budget, verifies how well a customer defined the requirements, helps forecasting a risk, etc. In a project where a customer is against Scrum it could be used at some point, in the middle of the project to show how much effort was wasted creating it, since most probably, later on, the modified plan would be far from the original one.
Summarizing, I'm quite sure that in some cases I'll use WBS even in the Scrum projects. It is important to remember that we decide what WBS really contains and how detail it is.
Some people things that WBS is something totally detached from Scrum. I don't agree with this. First of all if we would show a product backlog and a sprint backlog as a structure, we could consider it to be WBS. The main difference would be related to the fact that WBS must cover 100% of the work effort what means, that we at least have some placeholders for the work which is unknown at the moment. Regarding similarities, PMI Book explains that WBS decomposition for a deliverable or a subproject that will be accomplished far into the future may not be possible. In that case the team waits until they have more knowledge (Rolling Wave Planning) - sounds like Scrum to me:).
Recently my colleague asked an interesting question. He said that he already has WBS for his project but he would like to start following Scrum, he asked what he can do with it? It depends on the WBS which he has, but most probably with small modifications, WBS items could be used as themes, stories and tasks. In addition Scrum doesn't say that you can't have a detailed plan in the beginning, it just says that it might not make sense to have one and that it might be misleading. WBS items could be helpful during Sprint Planning meetings or calculating an initial team velocity and an initial release schedule.
It is also important to remember that WBS is not meant only for PM, but it is also a communication tool, shows a customer why a project is estimated for a certain budget, verifies how well a customer defined the requirements, helps forecasting a risk, etc. In a project where a customer is against Scrum it could be used at some point, in the middle of the project to show how much effort was wasted creating it, since most probably, later on, the modified plan would be far from the original one.
Summarizing, I'm quite sure that in some cases I'll use WBS even in the Scrum projects. It is important to remember that we decide what WBS really contains and how detail it is.
Subscribe to:
Posts (Atom)