Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Scrum
First Scrum Project - Please advice
Network:659



Hi,

I work with a startup and we have an upcoming project which I have decided to execute using Scrum. I have two team members who are developers (they will work on Python/Django) and one UI/UX developer.One of the Python/Django developers will be working 60% of his time on this project as he is also working on another project for which he will be devoting 40% of his time. The UI/UX developer will not be collocated with the rest of the team as he belongs to another organization. I have identified the Product Owner for this product and I will play the role of Scrum Master. I understand that we first need to have a product vision created by the Product Owner and which will be expressed in the product backlog. We will try to create fine grained user stories in this backlog. We not yet decided the duration of the sprints, but, since we feel that this would be a comparatively small project, we would be having sprints which are of 2 weeks. We would be having sprint planning meetings of approximately two hours at the beginning of each sprint. We would also be having a daily standup (we will involve the UI/UX developer via conference call) of 15 minutes.We also plan to have a sprint review and then a sprint retrospective meeting at the end of a sprint.

I have read through the theory of Scrum and I am not sure of the way estimations are done. I understand that we need to create story points for each story. But, my concern is the following - how do I estimate the total hours for this project. I had read once that 1 story point = 4 hours of estimated work, Is that the right way of estimating a scrum project?

I am sure that there are many project managers in this group who are using scrum on a daily basis. Would appreciate if someone could suggest a way to estimate this project.

Looking forward for some constructive advice. If I have made any mistakes in my understanding of a scrum project, please feel free to correct.

Thanks
Sachin Bal
Sort By:
Page: 1 2 3 4 next>
Network:9388



The "1 story = 4 hours" is just a guideline. The simplest answer to "how do I estimate the total hours for this project" is, you don't. The team (developers estimate hours, not the Scrum Master. Provided the stories are detailed enough for estimation, the team doing the task will estimate it in ideal time (hours estimated as if there were no other distractions). However, they will need to or should factor in things like testing, refactoring etc. This can be difficult and some developers estimate a percentage of the task estimate for these purposes. Estimates should also be in ranges to account for uncertainty. Effort that is estimated in hours or points will help to develop a schedule or completion date for a set of features or stories. You have to be careful here as estimating in story points will be a true indication of duration rather than effort since the velocity already takes into effect down time. However an estimate in hours is done in ideal time and does not take into account down time, so you will need to factor this in when forecasting dates for story/feature delivery. This doesn't really matter per sprint, because everyone knows what the team has has committed to for that iteration; it's more applicable to future iterations and releases where the customer may want to know "how much can we get done by this date?"
Network:659



Thank you for the quick response.

I agree that the estimations will be done by the developers (possibly with inputs from the product owner) and not the scrum master. But, the customer will still ask for the total duration it would take for the product to be delivered to him. So, how do we estimate the duration?

What I am reading from the response is that we should take 1 story = 4 hours as a guideline and then add some additional percentage to cover for things like testing, refactoring, some buffer etc.

Is my understanding correct?

Thanks
Sachin Bal
...
1 reply by Sante Vergini
Apr 09, 2018 12:41 AM
Sante Vergini
...
Hi Sachin, in that case, the duration or schedule will total the hours estimated for each task and then you need to factor in taks not directly related to coding, such as sprint meetings, retrospectives, distractions, other responsibilities the team members have in the organization (ie. training, org-wide meetings), usability testing, backlog refinement, vacation, sick days and the list goes on. Most projects estimate the capacity of the team and just throw in the rest as the balance. For example, a good rule of thumb might be that an individual team developer's capacity is 30 hours a week, which leave 10 hours for all those other things. You should be making estimates fairly high level. You mentioned the customer will ask for total duration. That tells me you are the beginning stages of your project, which means it may not even be feasible to do estimates in hours. They won't mean anything if they are done too early because the user stories haven't been fleshed out enough.
Network:9388



Apr 09, 2018 12:28 AM
Replying to Sachin Bal
...
Thank you for the quick response.

I agree that the estimations will be done by the developers (possibly with inputs from the product owner) and not the scrum master. But, the customer will still ask for the total duration it would take for the product to be delivered to him. So, how do we estimate the duration?

What I am reading from the response is that we should take 1 story = 4 hours as a guideline and then add some additional percentage to cover for things like testing, refactoring, some buffer etc.

Is my understanding correct?

Thanks
Sachin Bal
Hi Sachin, in that case, the duration or schedule will total the hours estimated for each task and then you need to factor in taks not directly related to coding, such as sprint meetings, retrospectives, distractions, other responsibilities the team members have in the organization (ie. training, org-wide meetings), usability testing, backlog refinement, vacation, sick days and the list goes on. Most projects estimate the capacity of the team and just throw in the rest as the balance. For example, a good rule of thumb might be that an individual team developer's capacity is 30 hours a week, which leave 10 hours for all those other things. You should be making estimates fairly high level. You mentioned the customer will ask for total duration. That tells me you are the beginning stages of your project, which means it may not even be feasible to do estimates in hours. They won't mean anything if they are done too early because the user stories haven't been fleshed out enough.
...
1 reply by Sachin Bal
Apr 09, 2018 1:02 AM
Sachin Bal
...
Hi Sante, I definitely need to give the customer some estimates as I will be using this information to arrive at the project cost which I am going to quote to the customer. The customer might look at the project cost and project duration and might take a go/no-go decision. Can you please suggest the right way to move forward?

Thanks
Sachin Bal
Network:659



Apr 09, 2018 12:41 AM
Replying to Sante Vergini
...
Hi Sachin, in that case, the duration or schedule will total the hours estimated for each task and then you need to factor in taks not directly related to coding, such as sprint meetings, retrospectives, distractions, other responsibilities the team members have in the organization (ie. training, org-wide meetings), usability testing, backlog refinement, vacation, sick days and the list goes on. Most projects estimate the capacity of the team and just throw in the rest as the balance. For example, a good rule of thumb might be that an individual team developer's capacity is 30 hours a week, which leave 10 hours for all those other things. You should be making estimates fairly high level. You mentioned the customer will ask for total duration. That tells me you are the beginning stages of your project, which means it may not even be feasible to do estimates in hours. They won't mean anything if they are done too early because the user stories haven't been fleshed out enough.
Hi Sante, I definitely need to give the customer some estimates as I will be using this information to arrive at the project cost which I am going to quote to the customer. The customer might look at the project cost and project duration and might take a go/no-go decision. Can you please suggest the right way to move forward?

Thanks
Sachin Bal
...
1 reply by Sante Vergini
Apr 09, 2018 1:18 AM
Sante Vergini
...
Have you defined all your user stories? If you have, and this is the beginning of the project, you need high level relative estimates such as story points. If you haven't defined the key user stories then you need to go back and do this with the team (or rather the Product Owner needs to do this with the team). If it is not the beginning of the project (and you have a defined story list and already estimated in story points previously) you can then break down all the stories into tasks and estimate these. I already outlined earlier than you can estimate your teams effort by hours or by velocity and then simply divide the tasks (if its hours) or stories (if it's points) to get the high level duration. Remember to consider the things I mentioned about non code-related tasks, and I can't assist you with that side as it is project-specific.
Network:9388



Apr 09, 2018 1:02 AM
Replying to Sachin Bal
...
Hi Sante, I definitely need to give the customer some estimates as I will be using this information to arrive at the project cost which I am going to quote to the customer. The customer might look at the project cost and project duration and might take a go/no-go decision. Can you please suggest the right way to move forward?

Thanks
Sachin Bal
Have you defined all your user stories? If you have, and this is the beginning of the project, you need high level relative estimates such as story points. If you haven't defined the key user stories then you need to go back and do this with the team (or rather the Product Owner needs to do this with the team). If it is not the beginning of the project (and you have a defined story list and already estimated in story points previously) you can then break down all the stories into tasks and estimate these. I already outlined earlier than you can estimate your teams effort by hours or by velocity and then simply divide the tasks (if its hours) or stories (if it's points) to get the high level duration. Remember to consider the things I mentioned about non code-related tasks, and I can't assist you with that side as it is project-specific.
...
1 reply by Sachin Bal
Apr 09, 2018 1:33 AM
Sachin Bal
...
In our case, we have not yet had our first meeting to discuss the product backlog. I shall initiate the meeting with the developers and the product owner and move forward from there. When we do the estimates, we shall also take into consideration all the non-code related, project specific tasks.

Appreciate all the help provided.

Thanks
Sachin Bal
Network:659



Apr 09, 2018 1:18 AM
Replying to Sante Vergini
...
Have you defined all your user stories? If you have, and this is the beginning of the project, you need high level relative estimates such as story points. If you haven't defined the key user stories then you need to go back and do this with the team (or rather the Product Owner needs to do this with the team). If it is not the beginning of the project (and you have a defined story list and already estimated in story points previously) you can then break down all the stories into tasks and estimate these. I already outlined earlier than you can estimate your teams effort by hours or by velocity and then simply divide the tasks (if its hours) or stories (if it's points) to get the high level duration. Remember to consider the things I mentioned about non code-related tasks, and I can't assist you with that side as it is project-specific.
In our case, we have not yet had our first meeting to discuss the product backlog. I shall initiate the meeting with the developers and the product owner and move forward from there. When we do the estimates, we shall also take into consideration all the non-code related, project specific tasks.

Appreciate all the help provided.

Thanks
Sachin Bal
Network:1340



Sachin, You got the king of Scrum, Sante Vergini. Sante is dragging my legs into scrum with his great knowledge.

Kevin D.
...
1 reply by Sante Vergini
Apr 09, 2018 5:16 AM
Sante Vergini
...
haha Kevin, yes you need to get bathed in Scrum.
Network:1528



You have started in the wrong direction. Sorry about saying that. First of all, if you will use story points estimations the worst thing you can do is to assign time to story points. By defintion you must not do that because is the first step to fail. that is used by people that do not know about Agile based methods and tried to do the same than in predictive environments. You will have a number of story points that you will commit to do in one sprint, no more than that. To know about how much you will do in one sprint you have to devide the number of story points by your velocity. Previously you have to define how much time (2, 4, other weeks) your sprint will take. So, I guess a question is into your head know: velocity?. When you use Scrum for the first time you have to spend at least two sprints to know how much stories (storie points) you can do into one sprint. That is velocity.Second, if you think you will have a project end date in advance you are lost. That is not possible. That is basic on Agile based environments. Third, all you related about the team is exactly the opposite you have to do when use Scrum. People must be together and must not be multitasking. No matter than that I am leading teams with the characteristic you stated but is a risk, LAST COMMENT: Houston, you have a problem. You are using something that is totally unknown for you (is my understanding based on your comment) and without previous impact evaluation. So, is time to stay clear about the risks.
...
2 replies by Sachin Bal and Sante Vergini
Apr 09, 2018 6:19 AM
Sachin Bal
...
No problem, Sergio. I welcome criticism as I am in a learning phase :-). So, let me understand your thoughts.

You are suggesting that I should define how much time would a sprint take. As mentioned earlier, I fix this at 2 weeks.

Next, you are telling me to commit a number of story points per sprint. How do I commit number of story points, if I have no idea to equate 1 story point to number of hours? Please comment.

Also, what you seem to be indicating is that a project done in Scrum/Agile cannot have an end date. I am not sure whether there is any external customer who would give a project without getting to understand the project duration and project cost. Please comment,

I agree with your third point that the team member should not be multi-tasking, but, we are in a situation where we have to manage with multi-tasking at least for one team member,

I also agree with your last comment, that I need to stay clear about the risks.

Thanks
Sachin Bal
Apr 09, 2018 6:26 AM
Sante Vergini
...
Sergio, first correction, no you don't need two sprints to determine a base for velocity. It is estimated at a high level in the very first iteration before velocity is even determined, based on what the team thinks they can achieve in the first sprint (ie. "We think we can do 30 points worth in this first iteration). This is corroborated in Mike Griffiths book "PMI-ACP Exam Prep" on page 300.

Further the Agile Practice Guide states:

"...lightweight estimation methods can be used to generate a fast, high-level forecast of project labor costs, which can then be easily adjusted as changes arise" (Agile Practice Guide, page 92).

Second correction, where did I say "assign time to story points"? I clearly said that story points are for high level estimates early in the project, and later on when the stories can be broken down into tasks, they can be estimated in hours. Velocity is most often calculated using story points, and hours are most often estimated using tasks. When I said "1 story = 4 hours is just a guideline" I am simply quoting the poster's own original statement. Mike Griffiths (the guy who was a major contributor to the Agile Practice Guide and the PMI-ACP exam) even states on page 267: "A user story is defined as a small chunk of business functionality within a feature that involves roughly 1 to 3 days worth or work."

Now having said that, this statement is not advocating estimating time from story points, as I am not advocating estimating time from story points. He is just pointing as (as I was) that the "rough" end-game of such a story might be 1-3 days, ergo a guideline, as we want a user story to be contained within a single iteration.

Third correction, your statement "if you think you will have a project end date in advance you are lost". Everyone knows that Agile projects are subject to change, and therefore and end date may not be certain. But the poster here asked about a situation when a customer asks for a duration (ie. with an end), and in that case we indeed do give an end date. May I remind you that in Agile projects, Time and Costs are fixed, only Scope may change. So the date will be fixed and the project will have X number of feature/stories, because we select the number of stories we can get DONE within the project's time/cost constraints. Unless of course the customer wants to add more scope (in other words it's not fixed anymore), then we can play with time and cost.

Finally, your comment: "all you related about the team is exactly the opposite you have to do when use Scrum. People must be together and must not be multitasking." I am not sure which of my comments drove you to mention multi-tasking and co-location. This is getting way off the track. Scrum makes no mention of multi-tasking (although it is not advised). This is a Lean concept, not Scrum, highlighted in Poppendiek's "Seven Wastes of Lean".

I suggest you carefully read posts in future (particularly mine because I bite back lol) before jumping to conclusions such as:

"All you related about the team is exactly the opposite you have to do when use Scrum." and "You are using something that is totally unknown for you."

Tranquility Base, we definitely know who has the problem!
Network:9388



Apr 09, 2018 1:38 AM
Replying to Kevin Drake
...
Sachin, You got the king of Scrum, Sante Vergini. Sante is dragging my legs into scrum with his great knowledge.

Kevin D.
haha Kevin, yes you need to get bathed in Scrum.
Network:659



Apr 09, 2018 4:43 AM
Replying to Sergio Luis Conte
...
You have started in the wrong direction. Sorry about saying that. First of all, if you will use story points estimations the worst thing you can do is to assign time to story points. By defintion you must not do that because is the first step to fail. that is used by people that do not know about Agile based methods and tried to do the same than in predictive environments. You will have a number of story points that you will commit to do in one sprint, no more than that. To know about how much you will do in one sprint you have to devide the number of story points by your velocity. Previously you have to define how much time (2, 4, other weeks) your sprint will take. So, I guess a question is into your head know: velocity?. When you use Scrum for the first time you have to spend at least two sprints to know how much stories (storie points) you can do into one sprint. That is velocity.Second, if you think you will have a project end date in advance you are lost. That is not possible. That is basic on Agile based environments. Third, all you related about the team is exactly the opposite you have to do when use Scrum. People must be together and must not be multitasking. No matter than that I am leading teams with the characteristic you stated but is a risk, LAST COMMENT: Houston, you have a problem. You are using something that is totally unknown for you (is my understanding based on your comment) and without previous impact evaluation. So, is time to stay clear about the risks.
No problem, Sergio. I welcome criticism as I am in a learning phase :-). So, let me understand your thoughts.

You are suggesting that I should define how much time would a sprint take. As mentioned earlier, I fix this at 2 weeks.

Next, you are telling me to commit a number of story points per sprint. How do I commit number of story points, if I have no idea to equate 1 story point to number of hours? Please comment.

Also, what you seem to be indicating is that a project done in Scrum/Agile cannot have an end date. I am not sure whether there is any external customer who would give a project without getting to understand the project duration and project cost. Please comment,

I agree with your third point that the team member should not be multi-tasking, but, we are in a situation where we have to manage with multi-tasking at least for one team member,

I also agree with your last comment, that I need to stay clear about the risks.

Thanks
Sachin Bal
...
2 replies by Sante Vergini and Sergio Luis Conte
Apr 09, 2018 6:50 AM
Sante Vergini
...
Sachin, yes you can have an end date, you just need to set expectations with the customer that in a highly dynamic environment such as Agile projects, while you will do your very best to fit the most amount of "Value" (scope) within the time/cost constraint, there are no guarantees, and that as the project progresses, you can get closer to knowing exactly how much work (stories/features) you will finish and a better feeling about the end date originally forecasted. People think that Agile contracts don't have fixed end dates. THEY CAN AND DO! However, you can adjust scope to fit that deadline, because it is the team that decides what scope it will do during each iteration.
Apr 09, 2018 10:19 AM
Sergio Luis Conte
...
What you stated is why I publish articles including inside PMI Network, I performed conferences around the world including PMI World Tour and today I am still "fitting" in my actual work place: Agile is not about to use a method. Is more deeper than that.
Here my answers:
1-about the sprint duration yes, that is what you have to do.Take care I am not saying that the sprint lenght is correct or not. I can not say that.
2-that is the shift you have to do when you use Agile based methods. Remember: requirements are not clear so the worst thing you can do is to tied points to time. That is because you must make experiments and that is because after you run Scrum and take notes you never know how much story points you can do into one sprint. That is the concept of velocity. Here is where your management team must change their mind.
3-once again, you are thinking as "traditional" (I hate this word) way where requirements are clear. You will have user stories which are so far from requirements and you will discover most of them when you run the process. The only thing you can do if a fix end date is required is use time-boxing. It does mean that you start from the end date, you will define the number of spints to fill up the time-box (for example is the end date is 1 month and you defined sprint duration of 1 weeks then you will have 4 sprints) AND THEN you will adjust your scope (product scope mainly) to that. Is up to you how to manage it.
4-as I mentioned I am working with Agile based methods from more than 20 years ago (I am one of the authors of one of the most referenced methods: DSDM) and if you ask me except from one or two (no more than that) intiatives I never have the possibility to work with collocated, dedicated teams. Including today where my teams are distributed along the whole world.
Page: 1 2 3 4 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"A good composer does not imitate; he steals."

- Igor Stravinsky