In this document, we describe the Keep development process from an organizational perspective. We identify events and artifacts allowing for a transparent, adaptable and predictable development process.
Sprint is a time-box of one week during which a product increment is created. Product increment is a sum of all items completed within the sprint by the team. Each sprint has a goal of what is to be built, and a plan guiding the building process. A new sprint starts immediately after the conclusion of the previous sprint. The scope of a sprint is identified during the sprint planning meeting. Individual team members may have a specialized area of focus but they all cooperate on the implementation of sprint items and accountability for reaching the sprint goal belongs to the team as a whole.
Milestone is a box of items identifying releasable product increment with no more than one-month horizon of development effort. Milestone contains items from one or more sprints. Each milestone has an expected delivery date assigned, evaluated from estimates.
The sprint planning meeting is a time-boxed event of one hour happening at the beginning of each new sprint where all dsciplines, such as growth, design and engineering identify work planned for the next sprint.
Planning meeting consists of two parts: retrospective and new sprint planning.
Retrospective part is time-boxed to a maximum of 15 minutes. During this part, the Keep team inspects how the previous sprint went. Every member has a chance to tell what in their opinion went particularly well and what could be improved.
The input to new sprint planning is product backlog, latest product increment, and any other prior planning work performed by specialized disciplines independently. The entire team collaborates on understanding the work that is going to be performed in the next sprint. Sprint planning should result in crafting a sprint goal which is an objective to be met by the implementation of items in the sprint.
Before each new sprint planning, engineering team meets to collaborate on estimating, breaking down, and discussing all the technical issues related to backlog product items. Engineering team consist of all disciplines involved in the software development process: research, devops, and developers.
Everyone is welcome to join the meeting but only purely technical subjects are discussed.
Engineering planning meeting is time-boxed to one hour.
At the beginning of meeting, there is a 10-minutes time-box for technical retrospective.
Before the meeting, tech lead sends to all participants a list of items from the top of the backlog that are going to be discussed during the meeting. Items should be presented in a clear way allowing the development team to understand all the details to the level needed. Each development team member should invest some time in preparation for the meeting by thoroughly reviewing selected items and writing down questions.
Estimates are provided by team members and should include enough development effort to meet the definition of done for the given item. At the end of the planning meeting, each individual item should have at least one team member assigned, but accountability for completion of the items in the sprint belongs to the whole team.
By the end of the engineering planning meeting, each team member should be able to explain how they intend to work to implement the selected items. Individual tasks may be clarified and re-organized later as more is learned.
The goal of the daily standup is to optimize team performance and collaboration. The target audience of daily standup is not primarily the manager; instead, it is a way for the other team members to track sprint progress, identify impediments, and synchronize about required development work.
Everyone should answer three questions for a daily standup:
-
What did I do since the last daily standup?
-
What will I do today to progress work towards achieving the sprint goal?
-
Are there any blockers that prevent me from progressing the work?
Development team members should be specific and provide enough details so that other team members know the current status, and if they work on the same item, what should they do next and in what order.
Yesterday
-
DKG result conflict resolution phase
-
Opened PR with a stub interface for the on-chain part: <link>,
-
Did initial work on off-chain voting event handling code, just local chain stub implementation, no PR yet.
-
Today
-
Continuing work on the DKG result conflict resolution phase
-
I received a review on my stub on-chain interface, want to address all comments. Should be ready today for another review round,
-
I want to finish Ethereum off-chain voting event handling code and open PR today. It will contain local chain stub implementation as well. Should be ready for review at the end of the day.
-
Blockers
-
I do not understand how conflict resolution phase votes are summarized, need to talk with someone about it.
When sprint item is described as “Done” everyone must share the same understanding of what “Done” means. For a milestone item to be considered as “Done”, the following requirements must be met:
-
The implemented code has been reviewed and approved by at least one other development team member
-
Code merged to
masterbranch -
The feature described by the item works as expected
-
The code is implemented according to the guidelines
-
No technical debt other than agreed in the item’s description
-
Tests implemented and passing
-
Item does not break other existing functionalities
We use GitHub to capture backlog items, plan development team work and track progress on sprint and milestone.
Each item is a separate GitHub issue. Each sprint has a separate board under the Keep Network project. Each milestone has a separate milestone board under Keep Network project. All backlog items are ordered under a separate backlog project in the Keep Network project.
All pull requests implementing sprint items reference appropriate issue.