- Review Retro Board (10 mins)
- Voting (2 mins)
- Discussion (15 mins)
- Summary Actions (3 mins)
- More comfortable with project structure and processes
- Happy with the rhythm currently present in the project sprints
- Nice to see this is being felt outside of development, in the feature / story preparation stages
- Better understanding of Grails and the project technologies, although at the expense of the first iteration taking longer.
- Code reuse between the 2 UI modules.
- Had time to pick up smaller tasks
- Feedback loop from testing to bugs being raised
- Transition form internal orgs to mod-organization-storage went fairly smoothly
- The management of the dev process seemed to be smoother.
- This project is often at bleeding-edge, and that can cause confusion as to where to find code or process that might be similar to what we want to achieve, to allow for reuse
- We're doing Phase 3 planning at the moment, including looking at potential (future) module dependencies
- We intend to flag these dependencies to other teams as soon as we have completed assessing the technical approach we intend to take
- The Washington meeting (June 2019) is an opportunity to negotiate scheduling early development of potential dependencies
- Improvements to release management for Stripes/UI modules may help mitigate a bit of the bleeding edge pain during delivery cycles
- We're also looking at how to accommodate system analysis as part of the onboarding / knowledge share process
- Testing can be problematic when we rely on 3rd party plugins, eg, Find Org
- Onboarding time and learning curve for Grails and related techs we use are often high at the beginning of a developers involvement.
- JIRA is often not updated inline with the projects processes.
- See discussion notes below
JIRA is often not updated inline with the projects processes
- The goal here is to
- have accurate current status of progress and obstacles
- reduce friction of Jira admin for all team members (including developers, testers, PO and scrum master)
- Leaving assignee unchanged helps make it easier to track work that has been 'owned' by a particular person
- This doesn't help identify who has responsibility for an item right now, although a combination of other fields may help
- Tester Assignee field could be used to identify who is responsible for QA
- Status of
In Code Reviewshould mean it's FAO
- Status of
In QAshould mean it's FAO
- Status of
For Reviewshould mean it's FAO Product Owner (the Jira
- Status of
For Releaseshould mean it's FAO Lead Dev
- If a PR hasn't passed code review, the Jira issue status is not changed back to
In Progress- the re-work is managed through Github to-and-fro
- Automating Jira transitions from Gtihub PR status could be done, if the integration has been set up.
- Needs some verification
- Automation will only be effective if only one PR is raised against each issue: exceptions would have to be manually handled
- Backlog / Kanban board filters in Jira have been set up to make it easier for leads and testers to identify items that need action based on status, rather than Assignee
- Checking these should be part of daily routine
Still to consider:
- Inferring current state of progress based on Jira status still relies on developers picking up and (self-)assigning issues
- Initial issue assignment could be handled in Sprint Planning.
- We do currently indicate who might pick up a piece of work in Sprint Planning log, but this isn't always reflected in Jira
- Some items will inevitably be left in the backlog or arise during the sprint
- A story will often have front-end and back-end work.
- These can (and should) be distinguished by separate subtasks
- Subtasks can be separately assigned
- Separate PRs can be raised against each subtask to support automated Jira transition
- But then, who should the story be assigned to? The PO?