jspahrsummers / scrumbut

Scrum, but with GitHub Issues (experimental)

ScrumBut

ScrumBut is a web app, built with Yesod, that adds Scrum features to GitHub Issues.

Despite Scrum’s focus on synchronous, co-located sprint meetings, ScrumBut will try to support asynchronous, distributed workflows as much as possible, to make it easy for remote workers to collaborate as well. This is why the project’s name comes from a derogatory term referring to teams that don’t use “true Scrum.”

Estimating stories

A particular team could start using one of their repositories by following these steps:

1. Everyone on the team signs in using their GitHub account.
2. One of the collaborators sets up that repository in ScrumBut, enabling Scrum features for it.

Once set up, any issue can be assigned story points as follows:

1. Collaborators submit story point estimates for the issue, along with an optional rationale for their estimate.
2. Once all team members have estimated the issue, a middle ground is automatically chosen if the estimates are close enough to each other.
3. If there are any big outliers in estimation, those users will get a notification and an opportunity to adjust their estimate, or else talk with the rest of the team about adjusting theirs.

Viewing progress

ScrumBut will treat GitHub milestones as sprints if they contain estimated issues.

After at least one issue in a milestone has been estimated, anyone can see the total number of story points in that milestone, as well as how many have been completed so far.

After a milestone with estimates has been completed, the total number of points will automatically be incorporated into a velocity that can be used to predict how many story points can be accomplished going forward.

Deployment

Although there are many possible ways to deploy ScrumBut, the only supported method is the Haskell on Heroku buildpack:

After the template has been deployed, you’ll need to set up private storage then build on a one-off PX dyno before the app can be used.

License

ScrumBut is released under the MIT License.

scrumbut's Issues

View all collaborators' estimates when viewing an issue

Estimates should be public as soon as they're submitted.

Calculate velocity from closed milestones

Once a milestone with estimated issues has been closed (completed), we should incorporate its points into a velocity calculation.

To simplify things, I think we should assume that each milestone refers to the same length of time.

Burndown charts

Using our calculated velocity and open milestones that have estimated issues, we should be able to predict how long it will take to reach any given point on the roadmap, and chart the results.

Issues outside of any milestone are not shown

This was supposed to be implemented in #22, but I missed it. 😞

Make site presentable

It looks like ass currently.

Include a rationale with submitted estimates

This would be useful to specify why a story is particularly large or small in your opinion, why you're disagreeing with teammates, etc.

Show an indicator when only some issues in a milestone are estimated

When a milestone has at least one estimated issue, but they're not all estimated, we should show some kind of warning or indicator to highlight that. Otherwise, the totals could seem disingenuous.

Fetch and store a list of repositories and their issues

If we're going to annotate issues with story points we'll need to store repositories and issues in the database.

View story point counts for a milestone

Including total estimated points, points completed, and points remaining.

GitHub Enterprise support

Right now, everything is hardcoded to GitHub.com.

Automatically find a middle ground estimate

This should only occur once there are enough estimates to make it meaningful. Maybe this could be a configurable amount later, but maybe the first version should require the whole team to specify an estimate.

The middle ground should probably be a median, not a mean, since that'd better handle outliers.

Authenticate with GitHub.com

Maybe the home page is just a big ol' Authenticate button until signed in?

We'll have to persist a user. Snap provides Snap.Snaplet.Auth, but I'm not sure where the records are stored. There's probably a way to set up a postgres backend.

Roll all tokens

While developing, we can be fast-and-loose with token embedding in the code—but before this repo gets made public, we need to roll any credentials used within it.

Heroku deploy fails

https://dashboard.heroku.com/apps/scrum-but/activity/builds/4f822641-ce5d-484c-9569-d9c6435833dc

-----> Determining constraints
       cabal: Could not resolve dependencies:
       trying: ScrumBut-0.1 (user goal)
       trying: base-4.7.0.2/installed-bfd... (dependency of ScrumBut-0.1)
       trying: lens-4.7 (dependency of ScrumBut-0.1)
       Backjump limit reached (change with --max-backjumps).
�[1m   *** ERROR: Failed to determine constraints�[0m
�[1m   *** ERROR: Failed to deploy app�[0m

 !     Push rejected, failed to compile Haskell app

Fetching resources requires all parents to be fetched

For example, to get issues in a milestone currently requires that you have the full repository and full milestone models. We should instead allow lookups by short IDs (for example, those that might be passed in URLs), to avoid excessive API traffic.

README-driven development

Describe the goals of the project in the README.

Login session expires constantly

I'm not sure if it's a really short timeout, or some transient state that isn't getting persisted, but I feel like I have to log in most times I open the site.

It's not every time, though, because opening new tabs and going to the page works as if I'm still signed in.

Allow any collaborator on a repository to submit an estimate for issues

Their estimate will be considered along with those of their teammates. No one person's estimate becomes canonical.

Order issues within a milestone

This would be cool to have, but I don't yet know how we could make it fit an asynchronous workflow.

Move to a service-oriented architecture

We could write a backend with something like servant, then consume that API with a frontend server.

This would have the nice benefit of forcing us to create a great backend API, which can then be consumed by third-party clients as well.

Notify users who submit estimates that are outliers

If someone significantly deviates from the middle ground, they should be notified. This will give them a chance to adjust their estimate, or talk to the team about why they think everyone else's estimates need to be adjusted.

Add a Deploy to Heroku button to the README

See Creating a 'Deploy to Heroku' button, and mietek/github-callback as an example.

GitHub requests do not automatically paginate

We should also fetch with per_page=100, to minimize the number of pages we need to download.

Markdown rendering

Issue (and milestone?) bodies should be automatically rendered as Markdown, just like GitHub.