Freelancing (?) programmers here: How do you estimate how many scrum points a specific project will require? Is there a template?

Submitted ⁨⁨6⁩ ⁨months⁩ ago⁩ by ⁨erayerdin@programming.dev⁩ to ⁨programming@programming.dev⁩

I know this is kind of a soft problem and is highly dependent on the context of a project.

For my own projects, I use scrum points to estimate how much effort it will require to reach to a certain point. I measured my throughput and it seems like, with the amount of time left from my daily job, I can complete around 100 points every month.

Recently, this idea is stuck in my head. Every (web/mobile) project requires a certain set of requirements such as:

Authentication and authorization
Performance metrics and logging
Storage
CRUD for each model etc.

Of course, mostly through Firebase.

I was wondering if there’s a way, a website or a platform maybe, to define a list of features/stories and get an estimated total points.

source

Comments

Sort:hotnew top

leaskovski@kbin.social ⁨6⁩ ⁨months⁩ ago
The idea is it doesn't matter what points you give something. What matters is that you are consistent with how you do figure it out, as then over time you will be able to get a velocity that you can use to predict the amount of work you can turn over. That's how I see it anyway.

source
makeshiftreaper@lemmy.world ⁨6⁩ ⁨months⁩ ago
As a Scrum Master myself this isn’t a question anyone outside of your work flow can answer. I’ve worked at organizations where we expected people to complete 8 points of work per sprint, and some where we expected people to do 30. Additionally, from a pure philosophy stand point, points measure complexity/uncertainty not time needed to complete the task. As such, you should be both reducing the average number of points per feature and increasing your average velocity over time.

OK, semantics aside, here’s some useful advice: jira has free accounts for individuals (check with their licenses before you sell any work) and is obviously built for software development. You can also install addons like Clone Plus that will let you clone epics and the stories within them. I’d recommend making a shell epic that contains the maximum amount of work a project would take, then appropriately size, sequence, and relate all stories to each other. After you have that template epic you can clone it and all the relevant stories underneath, then using Jira dashboards put them in the order they need to be done and use your estimated weekly velocity to see what you can do. Then you’ll have a list of tasks, how many points they total, and a rough timeline of story delivery

source
footfaults@hexbear.net ⁨6⁩ ⁨months⁩ ago
Story points are unique to the team that is doing the work. Basically, a 21 point story for me could be a 3 point story for you.

In of themselves, the points are not important. Just size the stories to some amount of points that is reasonable and then do a sprint. The objective is to get a sense of how much work can be done in a sprint, to help create forecasts of when work will be completed.

source
abhibeckert@lemmy.world ⁨6⁩ ⁨months⁩ ago
What works for me is only estimate short term work. Estimating work 100 points into the future is a waste of time. You will be wrong. Every time.

100 points is an average of 5 points per day. I recommend limiting your estimates to maybe 3 points. Because even if you get 5 points of work done today… it probably won’t be 5 points spent on what you planned to work on when you start the day. You need to plan for the unexpected and 2 points per day, every day, sounds about right to me.

Also if you think a task is worth 2 points, but you’re going to start work on that task tomorrow… then it’s a total waste of time to spend 10 minutes estimating the task now. Between now and when you start on the task you might decide not to do it, or make changes to the scope that significantly increase (or reduce) the amount of work required. Stick to “I can get these tasks worth three points done today”. Also try to split your project up into tasks that are 1 or 2 points (personally, I’d adjust your point system as well… a “point” is worth 30 minute at my company… and aim for 5 hours per day).

When you’re doing long term plans - don’t get into specifics. That works for other industries but it does not work with ours - our work is inherently unpredictable.

Rather than calculating an amount of time required - my long term plans are deadlines for certain milestones such as “ship a minimal viable product for QA/Testing” or “Finish the model for X” or “Setup performance metrics”.

Figure out what your budget is (say, $200,000 - or 2,000 points if you prefer), then split that budget proportionally among each milestone. Maybe your “performance metrics” milestone gets 100 points. That does not mean you think it will be 100 points of work. It means 100 points is the amount of time you are capable of spending on it right now. Assume it will be very different when you actually start work on it - regularly adjust points as you progress through the project. Maybe something is finished ahead of schedule and you decide to allocate extra points to something that could benefit from more work. Or maybe (more likely?) you’re behind schedule and you decide to cut something from the to-do list (as in, move it to the backlog, or reduce the scope).

Discussions around how much a project will cost should be less about the work required and more about how much you and the customer are both willing to allocate to the project. And if it feels like it can’t be done within the budget, then you don’t go ahead (for that you need to rely on experience - there’s no teach it). There are almost always corners that can be cut to reduce a 100 point project task down to something like half a point. Be prepared to do that - because it’s the only way to ship projects on time and on budget. Locking yourself into a detailed scope ahead of time doesn’t allow enough room to compensate for unexpected challenges or mistakes - both of which will happen on every long project.

source
solrize@lemmy.world ⁨6⁩ ⁨months⁩ ago
I’ve been at a bunch of companies that use those processes and at best they are like weather forecasting. You can figure out what season you are in, and you can predict the activity of the next few days, but beyond that they are imprecise to the point of uselessness. For freelancing you mostly have to have done such projects all-up before so you know what you are getting into, and have an idea of what code is out there that you can re-use in your projet. Expect to take horrible beatings on schedules multiple times. And be willing to turn away proposals if you’re not comfortable with the timeframes and other issues.

source