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.
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.
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!
...
1 reply by Sergio Luis Conte
Apr 09, 2018 10:07 AM
Sergio Luis Conte
...
First of all my post was not for you it was for Sachin so you are who must take care about you read.On the other side, sorry Sante, In a piece of paper or reading a book everything works find and everything could be interpreted as you want.
Just because it's a project you wish to deliver using agile methods doesn't mean that traditional approaches to top-down estimation go out the window.
At the very beginning when you've only elaborated on a small percentage of the work items in your backlog, it's quite reasonable to use methods like analogous estimation if you are asked for an initial estimate.
If you are looking for an "agile" alternative, you could t-shirt size all the epics & stories in your backlog, apply a rule of thumb to the t-shirt sizes (e.g. small = one week of effort), then add up the individual sizes to get a rough total, and divide that by some guesstimate as to how much work can be done in a sprint to figure out the number of two week sprints.
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
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. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Stories are weighted with story points to track burndown during the sprint and establish velocity. Based on the team's velocity and the number of known stories, a rough number of sprints can be determined. This will be refined as time progresses and more stories are created or adjusted.
You can determine what to take into a sprint through capacity based planning (# of developers/testers * 8 (minus 1 for each vacation day planned) or velocity. One way to determine velocity (how many points a team can deliver in a give timebox) is use the first couple sprints as the POC. Intelligently carry stories into the sprint and based on what is accomplished will determine your team's velocity going forward.
Points are based on complexity and effort. Many use Fibonacci - 1,3,5,8,13. All team members must agree on the assigned value
The budget goes to how much do they want to spend, how elaborate do they need the product - MVP Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Also, to point out. Set it up in such a way in which you think it will work. As sprints progress, you will refine (inspect & adapt!). Be flexible and determine what works best for your team and organization. Use the framework as the basis for your team's success. Saving Changes...
Some actually projects do estimate in sprints, that might be easier Sachin at the beginning. Define/prioritize the backlog, do high level estimate in points, first iteration is what your team says can be done in that timebox (later this will change as velocity is tightened), decide on a sprint length, then multiply it out to get the duration. Saving Changes...
Story points are the most common form of estimation is Scrum, but it is not the only one. Many people say ONLY points can be used. When that person can show in the Scrum Guide that this is the case, I will take notice. As long as the team is using the same estimation metric it's all good. But like Mike Griffiths says, you can use points, stories, hours, days and even "jelly beans" to estimate velocity which will assist in multiplying out the duration. I have used coffee beans to fill up a jar; a 3 dimensional burnup chart . If you have say 100 coffee beans assigned to a set of features in a release, fill up a jar with 100 coffee beans, draw a line on the jar where the coffee beans have filled up, then take the coffee beans out, and start filling up the jar after each Sprint. I should write this up in the scrum blog since there are so many coffee lovers out there :-) Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
