OppiaMobile Community

Updates to Oppia sprint management

At the moment, how we’re managing the sprint tasks has been by using the GitHub projects (linked directly to the github issues). However, from our experience with using this method with LMH and the Academy app in Liberia, there are some problems with this:

  • It means there are multiple project boards for each sprint (usually just for the app and server, but also potentially the moodle export block too)
  • If there are specific issues for an implementation (eg a specific registration signup interface in the app) we have 2 options
    • add the issue to the core app issue list (this doesn’t really make sense since the development is only for one implementation, and not the core)
    • add the issue to the implementation github issue and project list - but this then means there are additional project boards for the customer to look at
  • The github issues can be very specific (of course this is deliberate since they should relate to specific areas of code), but there’s not a way to tie together different issues that might relate to the same piece of functionality (eg for allowing users to update their profile info in the app, there are multiple github issues on the app and server needed for this functionality)
  • Alongside the github issues being very specific, there’s not a proper user story and set of acceptance criteria to know that the development work meets what is needed

In all, it’s very hard for the customer (and also the Digital Campus team) to see the full status for a specific sprint, since there’s not a single status page to go to.

A probable solution to all this is to move to using Jira or Trello (though Jira is the most likely candidate), so there is a single page where all the development for a particular sprint can be viewed.

I’ve made a very basic mock-up of how I think this page should look, see:

And the notes/workflow for this are:

A - there will be one board for each sprint - rather than having a backlog/to-do etc process that gets updated for each sprint. The rationale for having a different board for each sprint is that there is then a history (for funders) about what has been done in each sprint
B - the ‘to-do’ list for each sprint - the specific user stories will be created in collaboration with the customer
C - a specific user story for the feature/functionality
D - This is probably the most complex part to figure out. There should be a list of specific github issues for each user story - these will come from multiple/different github issue lists, and there should be some synchronisation here (eg if the github issue title is updated, comments/status are added/changed)
E - a set of criteria for each user story for the customer to sign off on
F - Once one of the issues in (D) is marked as being in progress, or a commit.PR has been made against any issue, it should automatically move to being in the ‘in progress’ column
G - Once all the issues for a user story have been marked as completed (the github issue closed or PR sent for each issue), the user story should automatically move to being in the for review column - the customer will then check against the acceptance criteria and sign off
H - When the customer has signed off on a user story it will move to the completed column

This, for me, is a very ‘ideal’ workflow, but would really like to make sure we keep these processes in-line with standards/norms for agile development - so any suggested updates/changes are very welcome (@patricia - I really hope you can help us here!)

A few potential things I see here with this approach:

  • How do issues such as code refactoring, updates for framework changes get reflected in these user stories (would it be that we’d have a user story for potential contributors/tech devs on the platform?)
  • User stories - there may be some stories which require particular functionality being delivered first - can we show a story being say 50% complete in one sprint, but then 100% complete in the next one

Any and all feedback on this would be much appreciated, certainly the current approach needs to be improved, but I just want to make sure we’re doing it all in a right/useful way