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.
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Apr 09, 2018 6:26 AM
Replying to Sante Delle-Vergini, PhD
...
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!
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. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Apr 09, 2018 6:19 AM
Replying to 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
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. Saving Changes...
Michael DelaneyPartner| Delaney Management LLCWest Chester, Pa, United States
Good question and excellent answers Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
It's ok Sergio, no one needs to be sorry. I think the thread is lost in translation. Most of my teams have been distributed also, it makes zero difference in Agile. People talk about co-location issues with distributed teams, but that is solved with technology. This is about estimation. The original post was to give the customer a date for completion, and this can be high level in any framework: waterfall, Agile, Lean etc. A date can and is given in most Agile and Scrum projects. It doesn't mean we meet that date, again that is based on what happens with the scope (ie. change). I have estimated Scrum projects in points, and I have forecasted Scrum projects in hours, it doesn't matter what the units are in, provided we use the same metrics within the project from the team up to the stakeholders. I don't understand why this is a contentious issue. Again, perhaps it's lost in translation, but unfortunately, I only have one language to communicate :-) Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Sachin, othe thing that is important to take into account when you use Scrum is which is the objective to estimate? Is not to know about time. The purpose of estimation is to help a team to forecast how much work they can take on in a Sprint. So, you are working with effort instead of time. That is basic if you use Scrum and that is critical to understand because is the main propose to use Scrum. I am not defending Story Points. In fact, if you are working into your first project with Scrum unless you have information or you have the time to collect the information do not use it. Remember the definition of estimation: best guess based on current information and time to estimate. Barry Bohem´s "Cone of Uncertainty" could give you an idea about how information impact inside estimations. And do not forget: is critical that those estimations must be done by developers and testers so here comes other ingredient: developers and testers expertise about you have to create to achieve each user storie. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
i had a hugh debate with Allen. I fully disagree with him. The name is #NoEstimates but when you read what they do they are making estimations. It is funny.
I really appreciate the efforts which each one of you have taken to respond to my questions. I will definitely use the contents of the mails to help me plan my first scrum. I personally feel that each of the responses would help guide me further.
Once I go through a couple of sprints I will reach out again and share my experience.
Thanks, once again.
Sachin Bal Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
i had a hugh debate with Allen. I fully disagree with him. The name is #NoEstimates but when you read what they do they are making estimations. It is funny.
...
2 replies by Drew Craig and Sante Delle-Vergini, PhD
Apr 09, 2018 4:34 PM
Sante Delle-Vergini, PhD
...
Finally we agree on something Sergio, that we both don't agree with Allen's article ;-)
Apr 09, 2018 5:02 PM
Drew Craig
...
Would love to have seen/heard that. LinkedIn or live? Link?
