3. Why process?
● Our members expect delivery on time
● We need to report on progress
● Identify blockers and slowdowns
● Work in harmony
● Job satisfaction
4. In a nutshell
Standup meetings
Defined every 4
weeks
Output captured in a
monthly cycle
continuously
maintained in the right
order
6. Development Sprint
● 3 Weeks Long
● Development (only) as fast as possible
● Code cleanup, tests writing, LAVA integration, upstream
submittal, and documentation
Definition of DONE
● Result must be demonstrable (Code should do something you
can show)
● Code must be testable (tests are written and ready for integration)
● Code must be upstreamable (in a shape to submit upstream)
7. Integration Sprint
● 1 Week long
● Integrate work into LAVA
● Code cleanup and upstream submission
● Writing documentation and updating wiki
pages
● Monthly release management
○ Tag source trees
○ Create release notes
8. Terminology
● Sprint Planning meeting (~2hrs)
○ All team members present
○ Select the user stories that will be tackled during the
sprint
○ Identify risks and dependencies
○ Self organize and start generating engineering sub-
tasks
● Standup Meetings (~15mins)
○ Each individual to report on
■ What was accomplished since the last meeting
■ What will be accomplished until the next meeting
■ Any blockers or slowdowns
○ Other matters must be taken offline post meeting
9. Terminology
● JIRA Engineering Updates (~10mins)
○ Engineers to add their engineering update into JIRA
using a predefined field every Thursday
○ Used to generate automated weekly reports targeted
at management and other engineering units
● Sprint Closing (~1hr)
○ Demonstrate the output using Google Hangouts
(maybe recorded)
○ Determine any left over work - aka 'technical debt'
○ Update JIRA with sprint output
○ Discuss obstacles and areas for improvement
10. ● Blueprint (Template Available)
○ Drafted by engineering
○ Reviewed and prioritised by the Technical Lead or
PM
○ User Story content
■ Deliverables - What will be delivered (not work items)
■ Acceptance criteria - What must be in place in order to consider this user
story complete (not what will be delivered)
Terminology
11. Relation between Engineering and
Linaro Roadmap in JIRA
Engineering Card
Blueprint
sub-task
sub-task
One to one relationship. Can be
confusing
Note: Epic Cards in the Linaro
Roadmap project are not
represented in the Linaro
Engineering project
Specific to the Engineering
Project. Actual engineering
tasks. Progress is tracked
against these tasks
Epic Card
Roadmap Card
Linaro Roadmap Project
Engineering Project
Epic Cards are subject to
approval by the TSC.
12. Terminology
● Roadmap Card
○ Very high level description of the goal
○ Includes use cases
○ Approved and reviewed by OPSCOM
■ engineering work
■ significant changes (eg deliverable changes,
dropping or adding new deliverables, changing
acceptance criteria or expected delivery date)
■ whenever there are work blockages
■ prior to closure (accepted or rejected)
13. What's Next?
Good starting point:
https://wiki.linaro.
org/OPSCOM/RoadmapProcessWithJIRA
Screencasts (WIP): Ask Serge for link!
Ask your Project Manager!!!
15. Work Backlog
● Work backlog covers the work to complete a roadmap
card
● Maintained by the TPM,TL or Director
○ Kept up to date
○ In order of importance
● Each Roadmap card will have its own backlog of user
stories
16. Sprint planning
● Select from the work backlog user stories the team will
tackle over the next two weeks
● Self organize who will take on what
● Break down the work into sub-tasks
● Focus on completing
the work in the
two weeks
● Once work starts,
no change is allowed
17. Rollout
● Plan to discuss this week and roll out next
● There is an adjustment period ~ 1 month
● Will work through the kinks together
● Nothing is written in stone. Keep an open
mind
https://wiki.linaro.
org/OPSCOM/RoadmapProcessWithJIRA