SprintCraft

Note: Some of these requirements are too specific and descriptive at this stage. We are planning an iterative process here, so lots of them are prone to change as we receive feedback from users.

Briefing

SprintCraft is divided into two parts, described below. At the moment the documentation for SprintCraft is in its README.
Note: We have added a [UX] suffix to some steps below. They contain some questions about the best way to present a specific feature to users.

Sprint Dashboard

The hourly estimates are one of our core parts of the sprint planning process. We use them to determine our capacity by comparing commitments with goals. This way we can be precise about the amount of work that should be added or discarded. As Jira does not offer an intuitive way to plan our sprints, we have decided to create an internal application called SprintCraft, which is our main tool for doing sprint planning sessions.

Sustainability / Budget Dashboard

The Sustainability Dashboards allows tracking the volume of time spent on internal projects. It displays the non-billable ratio of the work done by the whole team and individual cells.

The Budget Dashboard displays all used budgets within the chosen time. It is the central place for the team/cell-level budget management, as it aggregates and calculates budget-relevant data.

Phase 1

The discovery for the first phase can be found here. This part was focused on the initial steps of automating the asynchronous sprint planning process and has already been completed.

Phase 2

Rethink SprintCraft as a SaaS product

This is the preliminary step for the second phase of SprintCraft.

Landing page [UX]

[UX] Dedicated official project site - includes presentation of the project, features description, etc. Directs the user to create an account on our SaaS offer or to documentation to install it themselves.

Multitenancy [UX]

The goal is to run a single instance of SprintCraft, with open registration. Everyone will be able to register there. Therefore, we need to add a completely new layer for individual teams. The high-level plan of how this will be functioning is:

1. A team manager registers an account in SprintCraft.
2. A team manager is redirected to a team-specific subdomain, where an individual site can be configured.
3. A team manager invites team members with selected permissions.

[UX] This is going to be a part of the UX rework. Currently, the configurations are applied to the whole instance with env variables.

Currently, SprintCraft supports only per-instance configuration and does not have any permissions levels. Therefore, this is a big step, which needs to be broken down into smaller ones.

Configuration framework

To configure sites independently, we need to introduce a way to distinguish configurations between different sites. To do this, we will use Django "sites" framework. Initially, we could store site-specific configurations in a JSONField.

Roles

We will introduce team-specific roles using Django Groups. The roles will be the following:

1. Team Manager - these users can configure their sites, manage members and their roles. They can also complete a sprint.
2. Epic Owner - these users can add and modify budgets within their team.
3. Member - these users can see the Sprint, Sustainability, and Budget Dashboard. They can also create additional sprints if they want need to schedule tickets for the sprints that don't exist yet (Jira-specific feature).

Paid plans [UX]

The first iteration will not include the payment system, but we will handle it manually with invoices on FreshBooks at first when there are few users (like we do for Ocim for now).
We also need to provide a way to monitor new account creations and deactivate people who don't end up paying when we contact them at the end of their trial.

[UX] We should clearly state to users that it's a paid product, so we will include the pricing options (paid monthly plans with a free trial) on the landing page. Users should also be able to register interest, by entering an email for a waiting list.

Define supported tracking systems

In the long run, we want to achieve a fully pluggable architecture, which allows external users to install their extensions. First, we need to be clear about the range of the tracking systems we want to initially support.
Many of the existing workflows and behaviors are specific to our configuration of an older version of Jira that we're currently using, so we should get a better understanding of how other issue trackers are being used. We could do this iteratively - e.g. support newer versions of Jira first (or OpenProject, YouTrack, GitLab, etc.) and extract more service-specific behaviors to libraries. Eventually, we will and achieve full pluggability and extensibility of SprintCraft.

Reach out to Open Source communities

• List the project in open source directories (e.g. AlternativeTo).
• Ask other open-source projects for help with testing/specifying (host them for free, target adoption for feedback & contributions).

Licensing

Add copyright notices to all code files

Migrate to GitLab

As we have decided to move our repositories to GitLab, we could prioritize this step to have all merge requests in one place. This step includes:

1. Reusing the CI/CD pipelines from the crafty-bot repository and extending them with AWS S3 and AWS CloudFront support.
2. Using GitLab container registry instead of DockerHub.
3. Creating description templates for issues and merge requests.
4. Setting up security pipelines.

Estimate: 16h

Epic Update Reminder

On Thursday/Friday/Monday (the date is in flux with the changes to the async planning process), Crafty should use a Jira comment to remind the epic owner of every active epic to post an epic update. The functionality should be similar to the existing EpicUpdateReminder.groovy script, but implemented in SprintCraft; the old groovy script can then be retired.
Document this directive in our docs.

Estimate: 4h

Epic Due Date Reminder

Every day, the SprintCraft app should check if any active epics are about to reach their due date or are now "overdue" and then have Crafty leave a Jira comment for the epic owner to remind them about the upcoming deadline or ask them to update the due date. The functionality should be similar to the existing EpicDueDateReminder.groovy script, but implemented in SprintCraft; the old groovy script can then be retired.
Document this directive in our docs.

Estimate: 3h

Add Redux Toolkit

Adding Redux Toolkit will allow us to enable Redux DevTools Extension and greatly simplify reducers and actions.
The initial estimate has been bumped because we tried enabling this as part of another ticket, but this will require some changes due to the necessity of preserving state immutability (best practices). Additionally, there were some initial problems with nightly versions of Firefox due to the new functionality of having a limit of data that can be kept in Local Storage. We should make sure that this won't break on any browser.

Estimate: 7h

Improve UI/UX [UX]

[UX] We would like to make SprintCraft more intuitive and approachable in a way that would help to make our internal processes smoother and to encourage others to use this tool. We should also consider removing unnecessary toggles to make the interface less confusing.

Estimate: TBD (unknown frontend scope, this will likely be split into multiple tasks)

Abort pending requests after changing dates [UX]

When trying to change the date range for the sustainability data, the page starts loading data when either the start or end date is changed. In some scenarios, when the start date is in the future (e.g. I am trying to view the data for December after viewing the data for November), this causes the data to be loaded before the range is properly changed. After that, changing the end date doesn't update the data again. Only a page refresh fixes it.

[UX] We have two options here:

1. Abort pending requests after switching the date.
2. Add a button to click on for refreshing the data after changing dates.

Estimate: 4h

Improve documentation

Move the documentation out to ReadTheDocs, improve documentation (especially for the sustainability), add screenshots to describe each screen and feature.

Estimate: 11h

Improve error handling [UX]

Ensure that data retrieved from Google API cannot raise an unhandled exception. This point relates mostly to spreadsheets and API calls (sometimes Google breaks), for which using the wrong syntax in specific fields prevents the SprintCraft dashboard from rendering at all. We should still log such inconsistencies (e.g. to Sentry), but they shouldn't break the endpoints.

Estimate: 7h

Hide Sustainability dashboard by default [UX]

Most of the time spent in SprintCraft is related to the SprintCraft dashboard. Therefore, to reduce the number of queries, we can hide the Sustainability dashboard by default and display it only when a button is clicked by the user.

[UX] Should we split the sprint and sustainability dashboards? If no, what would be the best way to toggle the sustainability dashboard? Should we toggle it with a button, add a checkbox for this, or something else? Should we keep the user's choice in Local Storage or Session Storage? For reference, we are using Session Storage to keep From and To dates set for the Sustainability Dashboard.

Estimate: 2h

Gather and address feedback

Previous iterations of SprintCraft and Sustainability dashboards lead to heavy discussions. Therefore, we should plan plenty of time for gathering feedback, applying smaller changes, and preparing tickets for the potential small iteration after completing the MVP.

Estimate: 26h

Automate sprint completion

Automatically complete the sprint. This would be an equivalent of pressing the Complete Sprint button, but first, we should determine what to do with tickets that are not Ready for a sprint. This can be discussed during the "Gather and address feedback" step.

Estimate: TBD (unknown scope)

Budget enhancements [UX]

Some clients have a strict monthly cap on their billable hours that spans across multiple accounts - support and development. However, apart from setting up a budget splitting that cap based on past numbers, there is no way to set a cap for multiple accounts combined. This can be split into two different problems, described below.

Multi-account budgets

Some other clients have the budgets set for all of their accounts combined. Therefore, it's tricky to accurately track the usage of each budget, as it is going to require occasional tweaks to the proportions used for each account. We can introduce artificial accounts in SprintCraft, that will consist of multiple accounts. E.g. "Client Support", "Client Maintenance", and "Client Theming" will be listed as one account - "Client", with one budget set (as defined in this spreadsheet). We could also spend some time extracting current budgets' dates in SprintCraft separate models to make managing them easier - so that all changes to a single budget would be done from a single Django admin page.
Grouping accounts should be configurable - e.g. some internal budgets might also benefit from this feature, while for some client budgets separating accounts would not be desirable (e.g. when there are strict constraints for each budget).

[UX] How can we present multi-account budgets on the Sustainability Dashboard? We should be able to check the numbers from the sub-accounts too (e.g. have an accordion with sub-accounts as its content).

Estimate: 16h + TBD (unknown frontend scope)

Monthly caps

For some budgets, we cannot go beyond some number of hours per month. We could mark such budgets as "strict", which would indicate that time spent over a limit in a specific month would be counted as an overhead. However, this is going to make YTD and period calculations much more complex. Also, we would need a proper way to indicate a difference between standard and "strict" budget on the board.

[UX] How can we represent strict caps for budgets on the Sustainability Dashboard? Note: we're currently using a tooltip displayed while hovering over an account to see its monthly budgets.

Rough estimate: 24h + TBD (unknown frontend scope)

Cell budgets (allow to split an account budget between cells)

Currently, budgets are set per account. Now that we use several cells, each cell may want to have its budget (for instance for OC-MEETINGS). When viewing a cell’s dashboard, the overhead in each account needs to be calculated based on this cell budget, not on the global account budget. Implementation ideas (to be discussed):

• Having a global budget (as of now) and then storing the percentages: 30%+30%+40%.
• Explicitly setting the hours: 50+80+0. Then we either need to verify that the sum of the cell budgets matches the account budget that we currently set, or we get rid of the current budget field and calculate it via the sum of the cell budgets.
• Creating a different account for each cell. E.g. OC-FAL-MEETINGS, OC-SE-MEETINGS, OC-BB-MEETINGS, and continue using the current dashboard.

Estimate: TBD (unknown frontend scope)

Fixed budgets

Introduce the concept of fixed budgets - i.e. unused hours will be counted as "anti-overhead" and will increase the sustainability of the cell.
The "anti-overhead" should be counted only after the epic due date or once the epic is marked as done. Otherwise, adding the new fixed account is going to result in a significant improvement of the sustainability (as all the unused hours are going to be counted as the anti-overhead).

Show sustainability ratio of the next sprint [UX]

Create a new table that will show the division of billable/non-billable tasks in the upcoming sprint. Example table:

Units	Total	Non-cell	Billable cell	Non-billable cell	% non-billable cell
Story points	72	10	40	22	35%
Hours	894	165	472	257	35%

[UX] How can we add this without making the page cluttered?

Estimate: TBD (unknown frontend scope)

Add predictions to the Sustainability dashboard [UX]

Add a toggle to turn on predictions on the Sustainability board - if on, the numbers will indicate the sustainability calculated with an assumption that from the current day to the selected end date we are going to use 100% of all defined budgets.

[UX] How can we add this to make this feature intuitive?

Rough estimate: 20h

Easier installation

One-liner installation, without prerequisites and sensible defaults, is going to be tricky here, as SprintCraft won't work without setting many variables, like Jira credentials. Therefore, based on the approach introduced by Discourse, we can create a new repository that contains a base docker-compose.yml file, and a helper bash script that will generate configurations with variables provided by the user. It should also contain the script to upgrade an instance.
We can reuse parts of our playbooks for this (e.g. download docker-compose and deploy scripts directly from there), which would reduce the code duplication.

Rough estimate: 14h

Migrate from S3 to OpenStack Swift

As a FOSS project, we should look into reducing the AWS dependencies and replacing proprietary S3 with OpenStack Swift, e.g. using django-storage-swift.