[OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Jeanne Boyarsky wrote:Two things jump out at me:
1) A sprint for deploying to production. - the product should be production ready at the end of each sprint whether it goes to production or not. This means actually moving to production shouldn't be a big ceremony.
Agreed. It should be a 1 day work may be.
.
Jeanne Boyarsky wrote:
2) How do you know it will take 400 hours? .
by dividing by 4 are you referring to the work to be done in 4 sprints?Jeanne Boyarsky wrote: However, the work should be prioritized and re-planned each sprint, not just divided by 4.
Satyaprakash Joshii wrote:
If the number of resources will be 5 this will done in 66.67/5= 13.34 days.
Stephan van Hulst wrote:as long as you realize that you now only have a gross estimate of when the product could be deployed, an estimate that you should not get too attached to, as work is evaluated on a sprint-by-sprint basis. You can factor planned leave into your gross estimate, but unplanned delays may push back your schedule. Make sure you readjust your estimate at the end of every sprint, and inform people who depend on the estimate.
[OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Satyaprakash Joshii wrote:
If the number of resources will be 5 this will done in 66.67/5= 13.34 days.
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
How to Ask Questions | How to Answer Questions | Format Your Code
Junilu Lacar wrote:The rule of thumb is 7 plus or minus 2 for an ideal team size.
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
How to Ask Questions | How to Answer Questions | Format Your Code
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
How to Ask Questions | How to Answer Questions | Format Your Code
Junilu Lacar wrote:The teams I've had have been about 5-7 people, which includes members who focus on tests, db, etc.
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
How to Ask Questions | How to Answer Questions | Format Your Code
Junilu Lacar wrote:Regarding the original question, let's be honest: unless the work is more or less something you've done many times before and have a good sense of what it takes to complete or the variability is very low, it's disingenuous to say "We have this batch of work and we think it will take 400 hours to complete it." Statistically, you've probably underestimated that work by as much as 100%, maybe even more. It's the cone of uncertainty.
If you want to be truly honest and transparent, you might take a sampling of the work to tackle at first, get it done, then extrapolate from your experience what it might take you to complete the rest of the work. As you work on each small batch of work, you'll get a better sense of what's involved and will be better able to forecast what it will take to complete the remaining work. If there's a high degree of variability, then your best bet will be to break down the work into smaller chunks. Working with smaller batch sizes and working in timeboxes are two main strategies when working in an agile manner for managing complexity and being able to give better estimates.
Take the budget, divide it by a develope's salary, and divide that by number of developers.Satyaprakash Joshii wrote:. . . I just wanted to get a rough idea on how the rough estimate is derived. . . .
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
How to Ask Questions | How to Answer Questions | Format Your Code
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
How to Ask Questions | How to Answer Questions | Format Your Code
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
How to Ask Questions | How to Answer Questions | Format Your Code
Satyaprakash Joshii wrote:
While all members will contribute to the time to be taken, I think the time to be taken depends most on the developers who are doing the coding (more than the one doing QA, dB etc).
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
How to Ask Questions | How to Answer Questions | Format Your Code
Junilu Lacar wrote:Well you can set an arbitrary time box and plan to deliver whatever work you get done within that time. It's fine to have an initial estimate using the technique you gave but you should also plan to adapt your plans based on what actually happens as you complete each sprint.
That's why the preferred term now is "forecast" because it's really a lot like how meteorologists try to give people an idea of what's going to happen. Forecasts are much more reliable as you get closer to the actual date. If you have a 30-day forecast, what you think might happen 30 days out might be very different from when you get to 10 days out or 3 days out.
Junilu Lacar wrote: If you want to avoid that then it's better to be honest with yourselves and say up front "we think we can get all this done based on what we know now but that could change as we learn more. Make your plans accordingly."
Junilu Lacar wrote:This is really a big topic that gets you into things like value streams, bringing the work to teams, agile budgeting and finance (fund teams and value streams, not projects) and a whole slew of other aspects. Time boxes, small batch sizes, planning and replanning around evolving forecasts, these are all just a small part of a large complex picture.
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
How to Ask Questions | How to Answer Questions | Format Your Code
Remember that development doesn't follow the usual rules of arithmetic, so your 22.2 will be miles out.Satyaprakash Joshii wrote:. . .
6. He knows that since developers will be only say 6 hours productive in the day instead of 8 hours it will take 400/6=66.67 days for 1 developer.
7. He knows that since there are not 1 but 3 developers so it will be approximately 66.67/3 = 22.23 days to do this.
. . .
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
How to Ask Questions | How to Answer Questions | Format Your Code
Junilu Lacar wrote:A great deal of the variability in software development comes from people. People are not robots. Their ability to complete tasks may vary from day to day, positively or negatively. If you're stressed or distracted by things like a pandemic, for example, then the 6 hours of productive time you had last week may not be enough to produce the same kind of output this week.
[OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Junilu Lacar wrote:I was holding off but since Dave broached the topic, I have seen a number of organizations who do a lot of testing at the system level, mostly manual end-to-end even for things that ought to be tested at the unit/module/component integration level. These kinds of organizations tend to have way more testers and much longer test cycle times. This is also where you'll see such antipatterns as a sprint for development, a sprint for testing, a sprint for hardening, and maybe even a whole sprint to deploy. That is not agile, of course. So the estimates that developers give are really what is traditionally called "code complete" effort.
Dave Tolls wrote:I'm of the opinion that many devs are not great at that sort of test writing and having someone around with the right mindset helps immensely.
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
How to Ask Questions | How to Answer Questions | Format Your Code
That is a good point to understand.Thank you.The main difference here is that we don't go around the circle and let each person talk. The focus is not so much on each person but on each card that's on the board.
An Agile team doesn't form around a project, then disbands when the project is done.
Again, people are not plug-and-play cogs in a machine that you can easily switch out. Each person is unique and brings their own perspective, skillset, and experience to the table.
The math is that we average how many story points we got done per hour over the last three sprints and use that as a multiplier by the number of hours available.
The team gathers around the board (a physical board is still the best). Starting from the right side, we work our way to the left, from DONE, DOING, to TODO.
Again, it is the TEAM that estimates the work they are taking on, not just the team/tech lead.
Availaility for 40-(4% of 40) hours in the week. I think that it means out of 40 hours the team members would be 36 hours productive which comes to 36/5 around 7 hoursMy team has a spreadsheet where we enter vacation/training and such. We discount for a 10% "employee tax" (all hands meetings, timesheets, etc)
"The code is given to QA atleast few days before end of sprint." This is waterfall, not Agile. QA is involved early. QA helps write tests up front, to guide development and design
Sprint 0 and a sprint for deployment, as I said before, are carryovers from teams that cling to traditional waterfall practice.
3. "The team gives demo to the customer on the last day of the sprint." Sure, they can do that but they should also be engaging with the customer as they incrementally
build and design. The sprint demo should not be the first time the customer sees the software. Ideally, you have a customer or customer representative on site and
always available to give feedback and comments throughout the sprint.
Satyaprakash Joshii wrote:
Junilu Lacar saysAn Agile team doesn't form around a project, then disbands when the project is done.
If not this than what is the other way suggested?
Satyaprakash Joshii wrote:
Junilu Lacar saysAgain, people are not plug-and-play cogs in a machine that you can easily switch out. Each person is unique and brings their own perspective, skillset, and experience to the table.
Agreed. How does one bring these out( own perspective, skillset, and experience) during the daily meeting? In terms of DONE/Doing/TODO and any inputs if anyone has ?
Satyaprakash Joshii wrote:
Jeanne Boyarsky saysThe math is that we average how many story points we got done per hour over the last three sprints and use that as a multiplier by the number of hours available.
While the team member working on a task will estimate whether the task is easy/medium/complex, how are the story points mapped to the number of hours.
Also, how is it done for the first sprint where there is no historical data?
Satyaprakash Joshii wrote:
Jeanne Boyarsky saysAvailaility for 40-(4% of 40) hours in the week. I think that it means out of 40 hours the team members would be 36 hours productive which comes to 36/5 around 7 hoursMy team has a spreadsheet where we enter vacation/training and such. We discount for a 10% "employee tax" (all hands meetings, timesheets, etc)
a day.Since you talked about further discount then I think it can be around 6 productive hours a day.
Satyaprakash Joshii wrote:
Junilu Lacar saysSprint 0 and a sprint for deployment, as I said before, are carryovers from teams that cling to traditional waterfall practice.
In my company we have a practice of sprint 0, so was never having an idea that it is a waterfall practice instead of agile. Some tasks like installation, setup , getting access etc are done in Sprint 0. So when would these be done in agile if there is no sprint0?
[OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Jeanne Boyarsky wrote:Or all those admin things can be done before the project exists rather than having a sprint 0
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
How to Ask Questions | How to Answer Questions | Format Your Code
Surfs up space ponies, I'm making gravy without this lumpy, tiny ad:
the value of filler advertising in 2020
https://coderanch.com/t/730886/filler-advertising
|