Development / Programming work: Story points, etc.

[dckc]

@MParlikar , @lapin7 , and I discussed ways to improve bounties for software development, especially when they interact with the core dev team.

One result is that story points seems to be an important way to normalize things.

@MParlikar would you please explain how you normally use story points? I have a rough understanding of my own, but I'd like to compare my background with your practices.

Also... someone started tagging things with Programming which suggests that Development is not sufficiently clear (@Keaycee ? was it you? I forget...). Renaming Development to Programming is worth considering, but let's not have two labels. Maybe SoftwareDev? But I there seems to be this "D> " convention that argues for keeping the initial D... so perhaps DevSoftware?

[BelovedAquila]

@dckc I actually created that label and like you rightly guessed, it was kind of because the development label seem blurry and limited. I suggest it did be more precised if it's actually renamed "software development" or " software programming ".

[MParlikar]

We use story points as a rough estimate of effort. It is a Fibonacci sequence, because as the number goes up, the projected error in the estimate also goes up. Typical story points are 1,2,3,5,8,13,21. 21 story points amounts to approximately 40 hours of raw effort (~ 2 weeks, including administrative overhead, productivity, etc...). As a rule, we strive to keep our tickets at or below 13 story points. Over time, the team's aggregate velocity (# of story points completed in a sprint) begins to 'normalize' to an average - and eventually, this can be used to estimate dates when a given feature will be released (depending on priority of the feature).

[notbdu]

Agree w/ most of what @MParlikar said. The organizations that I've worked at have generally stayed away from correlating story points to hours of labour. Reason being that the hours necessary to complete a task vary from engineer to engineer.

Story points as a measure of relative difficulty and aggregate team velocity makes total sense though.

[dckc]

#503 is a PR to clarify CONTRIBUTING.md w.r.t. developer work. It's currently conflicted with edits regarding the web app.

@KellyatPyrofex while you're fixing those conflicts, perhaps you want to integrate story point norms? Or in a subsequent PR?

Discussion with @MParlikar and others is converging around a norm of $40 per story point. Adopting that as a guide / norm is straightforward: we all just start voting that way (and with the trust metric, #375, votes from folks like Medha and myself will likely have more weight). I'm not inclined to make it a hard-and-fast rule; for one, I don't know how; for another, @lapin7 argues for some flexibility to reward exceptional work.

[MParlikar]

For exceptional work, what about a spot bonus program? That is what corporations do.

[Jake-Gillberg]

@dckc If 21 story points is ~ 2 weeks of work, $40/story point seems low for dev work at $10.5/hr. Am I missing something?

[dckc]

How would a spot bonus program be different from just voting a little differently in this existing bounty program, @MParlikar ?

[dckc]

yikes... $10.5/hr... I hadn't put 2 and 2 together like that, @Jake-Gillberg .

The market rate for scala freelance work is more like $50 to $90/hr.

https://www.peopleperhour.com/freelance/scala
https://www.payscale.com/research/US/Skill=Scala/Hourly_Rate
https://www.upwork.com/o/profiles/browse/?q=scala

[MParlikar]

I don't think the bonus program would be too different from a voting perspective. The budgeting side would be different, and perhaps you could have more votes needed for the bonus. With respect to the hourly rate, we don't have many tickets that are 21 story points. 21 story points means that the engineer doesn't really know what it is going to take to implement the feature. 8 story points ~ 2 days which translates to approx $20 - $30 / hr.

[lapin7]

The discussion of rewarding DEV-work should have effect on how we reward other work. It seems to me that other work is rewarded at a higher rate then DEV-work and I would like to see the opposite. At the moment DEV-work is most important for RChain to succeed.

If we look at the 5 key business functions: Development, Marketing, Finance, Legal, Operations then all have to be excellent. But when there's no Development then the whole project fails for sure. Luckily the DEV-management is in good hands of Pyrofex, i.e. @MParlikar :-), but more community involvement would be great. This involvement would help to get more experienced RHOlang developers.

So either we increase the rate for 1 story point for DEV (see the comments of @dckc and @Jake-Gillberg) or we try to implement more control on the results of the other business functions.

We have now a good working reward system and we have about 150 RChain Active Members. That means that we can apply more strict management, without discouraging the decentralized self management.

[MParlikar]

If the development work is not rewarded higher than other work, then I agree with @lapin7 here. If we want to take the market rates for a Scala Dev at peg it at $75 / hr, Then I propose a first approximation of $150 / story point, since 8 story points ~ 2 days, 5 ~ 1 day, 13 ~ 4-5 days. If everyone on this thread agrees, please say so - so I can start approving bounties for March.

[AbnerZheng]

I agree.

[lapin7]

I agree with $150 / story point.
That is to say when the pay out is 100% in RHOC.

[dckc]

@Jake-Gillberg would you please edit the results of this discussion into CONTRIBUTING.md? Kelly Foster made a relevant contribution in #503, but it needs conflicts resolved.

[dckc]

TODO: add this to #783 for the EC etc.

[dckc]

discussion with @ddayan , @MParlikar , Ned ...

guestimate: $15 to $20 K per month going forward for core-dev, based on historical data, noting that @MParlikar has another dev ramping up in addition to the great work @AbnerZheng has been doing.

@ddayan to follow up with @kennyrowe about how this connects to coop budget processes.