Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sprint #5.2: Pavel's 80/20 #1918

Closed
zavreb opened this issue Feb 27, 2018 · 19 comments
Closed

Sprint #5.2: Pavel's 80/20 #1918

zavreb opened this issue Feb 27, 2018 · 19 comments
Assignees

Comments

@zavreb
Copy link

zavreb commented Feb 27, 2018

No description provided.

@zavreb zavreb changed the title Pavel 80/20 Sprint #5.2: Pavel's 80/20 Feb 27, 2018
@zavreb zavreb added this to the Sprint #5.2 | Mar 02 - Mar 15 milestone Feb 27, 2018
@aksonov aksonov self-assigned this Mar 9, 2018
@zavreb
Copy link
Author

zavreb commented Mar 13, 2018

Err, what is this ticket waiting on? I believe the specifics of this ticket was posted on #development but I'm not sure what this ticket addressed.

@bengtan
Copy link
Contributor

bengtan commented Mar 14, 2018

Are you expecting that the devs tell you what they're doing in their 80/20 time?

They might not always have something to report.

@aksonov
Copy link
Contributor

aksonov commented Mar 14, 2018

@zavreb I described my work within Friday's standup. Also I talked with Beng to make Friday as a day I'm working on 80/20. Btw, I don't know what is required actions for this ticket (close/re-open every Friday or create new one, etc.)

@zavreb
Copy link
Author

zavreb commented Mar 14, 2018

@aksonov the 80/20s are 5 story points (~1 day or sometimes more) per dev, a total of 10 story points out of 50 points in a sprint. If you separate your ticket for "half" on one Friday and "half" on another Friday, feel free to keep it opened on In Progress.

Once you're done with your 80/20 please feel free to close. One is created for every 2 week sprint.

It'd be helpful if you and @southerneer can comment your descriptions in these 80/20 tickets to avoid duplicate scheduling. (Can talk about this more on Thursday)

Adding it:

Worked on my 80/20 ticket. Discussed with react-navigation authors (Eric Vincenti and Brent Vatne) upcoming 2.0 release, start playing with it - https://github.com/aksonov/react-navigation-experiments, found few issues: react-navigation/rfcs#29 (hopefully they will fix it) - we need that to upgrade RNRF (it still depends from react-navigation betas..) that used by our app.

@aksonov
Copy link
Contributor

aksonov commented Mar 14, 2018 via email

@zavreb
Copy link
Author

zavreb commented Mar 14, 2018

@aksonov, the 80/20 is based off of the two week sprint as a whole. A sprint is capped at 50 story points including the 80/20 rule. 20% of an entire sprint is 10 total story points. 10 total story points split between you and @southerneer is 5 story points per person each 2 week sprint.

If we do it the way you propose then that means it'll be 20 story points out of the Sprint. 10 story points for @aksonov and 10 story points for @southerneer. 20 story points out of a 50 point sprint is 30% of the sprint dedicated to the 80/20 rule. (cc: @thescurry)

We can speak further as a group on how we want to define the 80/20 rule.

@zavreb
Copy link
Author

zavreb commented Mar 14, 2018

@bengtan the reporting is meant so that we can make sure we don't duplicate the scheduling on the roadmap.

@southerneer
Copy link
Contributor

southerneer commented Mar 15, 2018

Haha ok, so the real discrepancy is what a story point means. Up to this point I think we've all gone with the assumption that 5 story points = 1 developer day. @zavreb by your math 2.5 story points = 1 day.

@bengtan
Copy link
Contributor

bengtan commented Mar 15, 2018

I second @southerneer's comment.

@zavreb:

How many story points do you think 1 developer-day is? 2.5 points or 5 points?

I've been going by the latter.

@aksonov
Copy link
Contributor

aksonov commented Mar 15, 2018

@zavreb 80/20 rules applies to a person, not to a team. Otherwise if we would have 10 engineers, then 80/20 (in your interpretation) means 1/10 (48 min?) of full working day...

@aksonov
Copy link
Contributor

aksonov commented Mar 15, 2018

@zavreb It is interesting how you are calculating (and why you introduced story points for 80/20). Sprint has 10 working days (for each engineer), right? So 20% is exactly TWO working days, not one.
It means that you defined story point incorrectly.

@zavreb
Copy link
Author

zavreb commented Mar 15, 2018

@aksonov (cc: @southerneer) you are right in what you are saying. It makes sense. Time and story points aren't meant to mix, story points only focus on effort level and shouldn't be quantified along with time.

If it's alright with @thescurry we'll define the 80/20 as two working days per sprint.

@southerneer
Copy link
Contributor

...and 5 story points = 1 dev day and therefore we should allot a total of 100 story points for 2 devs in a 2 week sprint, correct?

@zavreb
Copy link
Author

zavreb commented Mar 15, 2018

Our average velocity on two week sprints was 50-55 story points. But I have not been able to track our velocity lately due to shifts in Sprints. We haven't had a "perfect" Sprint in awhile and that average was taken in 2017. It is possible that our velocity has increased now that we improved the way we work (w/bugsnag + refactoring efforts + detox + having @southerneer fully ramped up).

For our next Sprint Estimation we can shoot for up to 100 story points and then reflect on the weight of the sprint and see if it makes sense.

Nonetheless, a 5 is not 1 dev day. A 5 refers to our effort level, it could be 1 day, 1.5 days or even 2 days.

Ultimately, story point efforts should not be equated to time, but effort level/difficulty. This topic has always been an issue for all agile teams. See link.

Furthermore, if we'd like to, we can try estimating in hours instead so that it makes sense with our 80/20 rule (which is measured in time). I have worked with teams that have tried this method, but though our story point estimations aren't perfect period, estimating with time is less perfect. But maybe that's what works for us.

Thoughts?

tldr/

  1. Story points do not equal to time.
  2. Our velocity has increased (but rz has been unable to measure it recently due to not having "near perfect sprints" and we should therefore calibrate our sprints for a higher velocity.
  3. We can try estimating in hours if we think it could work for us.

cc: @thescurry, @bengtan

@southerneer
Copy link
Contributor

Not suggesting changing the way we estimate time, just trying to reconcile

the 80/20s are 5 story points (~1 day or sometimes more) per dev

with

a 5 is not 1 dev day

@bengtan
Copy link
Contributor

bengtan commented Mar 16, 2018

We can try estimating in hours if we think it could work for us.

I don't think we need to change how we're doing the estimations. They're working fine (AFAICT) and they're a non-problem.

Story points do not equal to time.

IMHO, the step which tripped things up was trying to equate 20% time with 5 story points.

@thescurry
Copy link

Hey guys, I think I can fix the confusion here. The 80/20 rule should be very simple, it's based on time. So regardless if a sprint is one week or two weeks long, the easiest and fairest way forward here is to give 1 day a week to dedicate to the "20%". If we can all agree with that, I think we can move forward on this particular subject.

Do we all agree? :)

@zavreb
Copy link
Author

zavreb commented Mar 16, 2018

Sounds good!

@zavreb
Copy link
Author

zavreb commented Mar 16, 2018

I'm going to close this since Sprint 5.2 ended. I won't create future tickets for the 80/20, we'll just assume Fridays are the 20%.

cc: @thescurry

@zavreb zavreb closed this as completed Mar 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants