DXgov Agile Sprint Plan #322
rossneilson
started this conversation in
General
Replies: 1 comment
-
Updates: |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
👋 Welcome to discussions
Being an open-source project, discussions are a useful place to publically discuss ideas with stakeholders and users of DXvote/DXgov:
🏃 DXgov dev Agile Sprint trials
For our first discussion here is our plan to test out, for the first time, sprints in a DXdao development team.
I have some experience with sprints from JP Morgan where we received coaching and used it in our team for a few years. Agile wasn't followed perfectly and I don't think it has to be, but let's find what works best for our team and along the way, what's best for a DAO development team here.
Github
As a fully open source project that values transparency above all else we are going to try sprints without reliance on tools beyond our source control system of choice, GitHub (Maybe someday we could move to Radicle for a decentralised alternative).
Sprints
Sprints are fixed-length iterations on a project, usually with specific aims about what should be shipped by the end.
There is no set period for a sprint, they can be days, weeks but in most cases not more than a month. For us I think shorter, faster sprints are something we should strive for and although it may be difficult, starting with 1-week sprints I think would be a good experiment.
Since we need to refresh the cache and are a rapidly evolving product essentially being beta tested by DXdao we can line up the end of our 1-week sprints with a release and cache refresh. This way we are continuously shipping and receiving feedback on releases.
(Weekly releases will be merged to master and tagged but will not always update ens, this can be done maybe per month as a rollup)
Project Management
The issue with project management is that GitHub has very few built-in sprint management features, but we will manage.
Stories
User stories map fairly simply into Github issues and we will have a new template to encourage users to write stories for us in the style:
Sprints
Milestones make a decent but not perfect alternative to sprints.
For each week we will have a milestone named after the release version with issues assigned to that milestone.
(Unfortunately, these are on repo level, not org level)
Milestone:
Beta projects will also be used to view and manage these sprints with one project used as “Active sprint”.
https://github.com/orgs/DXgovernance/projects?type=beta
New beta projects:
Kanban example:
Backlog
Issues without milestones assigned will be considered the backlog.
We can also have a backlog project board to prioritise, prepare for sprints and groom the backlog.
Keeping a well groomed backlog is an important part of scrum and all developers should take some time to ensure the backlog does not have duplicate or finished issues in the backlog. However pm will have responsibility here.
Metadata
Sprint systems usually have additional metadata to add to user stories such as priorities and points. Previously we had only issues but now with the projects beta, we can add fields to an issue.
Issue example:
Points can be difficult to get your head around but moving forward as a team we will get good at estimating issues using these unitless points. The idea is that any issue should be estimated based on its complexity not how long it will take. And so a 2 point story should be assigned the same regardless of who implements it. This helps when estimating and planning future sprints capacity.
This data not being a first-class citizen of GitHub brings issues that make using the data difficult to calculate things like velocity difficult but I can handle this outside of Github in a spreadsheet going forward.
Issue flow
Global backlog -
Sprint Backlog -
In progress -
In review -
Done -
Issue movement in sprints
Left over issues -
The aim of sprints is to estimate so well that everything is completed by the end. Of course this is unrealtistic and so what do we do when a sprint ends and a task is still in progress.
Generally the task should not count towards the velocity of that sprint and will move into the backlog.
From there it can be prioritised and potentially moved to the next sprint.
This is why breaking down issues is important so they are manageable and not too large.
New issues -
If a developer finishes all their tasks for the sprint and has nothing to do then they should first consult with the team to find out if anyone needs any help with their existing tasks.
After this and if no work was found needing help the developer should look for an item to bring into the sprint.
However before working on it they must make public that they are increasing the scope of the sprint.
Ceremonies
Agile and scrum define four main events or ceremonies. Sprint planning, stand-up, demo and retrospective.
Sprint planning:
At the beginning of every sprint (every Monday for weekly sprints)
Begin with product backlog, estimate issues and create sprint backlog
Refer to previous sprint velocity to plan new sprint
Define goals, priorities and how sprint success will be measured
Daily standup:
Short updates from every member
Completed, working on, any blockers?
Fun and light
15 minute limit, additional conversation after main updates - optional
Encouraged to attend all, but let not strict - let us know and provide text updates if not able to make the standup
Demo / Review:
Typically at the end of each sprint
With weekly sprints these will be moved to only ens update releases (monthly)
Retrospectives (Retros):
End of every sprint (every Friday for weekly sprints)
What we did well or could do better
Actions
Github discussions will become the single source of truth for all the write-ups from our retros.
Going forward
If we find scrums and sprints work well for us we will continue.
We can also at any time consider changing 1 week sprints into 2 week sprints.
This will be measured as we use scrum to develop and ship guilds while continuously improving DXvote over the next few months where after a decision to continue or stop can be made.
Beta Was this translation helpful? Give feedback.
All reactions