As a team, we always need to find, analyze and solve the pitfalls of the processes.
Last year was a tough one, with COVID-19 making us stay at home and working via Zoom without any personal connection.
But at the same time, it seems that digitalizing the process inserts some order into our lives and enables us to measure the process even better.
So the process is running well for us, but as a constant improvement here are some of the items we are looking into:
- If the Front End team depends on the Back End team task, on completion of the Back End team task, the Back End developer should inform the Front End developer about completion on the highest level of items hierarchy.
- If Front End and Back End have different User stories, we need to add them to the parent Feature item.
- Build smaller features with several user stories and add to epic to create a connection between the Front End and Back End responsibilities.
- Set a sprint goal for the team to understand what to strive for and how to prioritize the time.
- It’s a must even if you set a sprint goal, to prioritize the remains of the prior sprint, to begin with, otherwise, you will drag your fit with those user stories throughout multiple sprints.
- Velocity – find a way to calculate needed empty hours – in our case, it’s about 7 hours a week as per weekly sprints we had. So for our classic approach of 2-week sprints, we are setting 14 hours of unexpected hours per 80 – it will include the daily meetings and all unexpected critical bugs to be added during the sprint – a bit less than 20% of the time.
- At the end of the sprint – create a wiki page summarizing the user stories to test and additional remarks for the tester to be able to test without approaching anyone. The tester should be able to work as a standalone without chasing around multiple stakeholders trying to get a grip on the needs and the test cases to cover.
- The developer should change the user story status as he progresses to active and then to resolved statuses.
- We will check the option to automate the process for the user stories to be updated automatically based on the inner items.
- The developer should add additional technical Acceptance criteria at the user story or bug work item for the tester to test the user story without approaching the developer.
- The developer should define the needed tasks during estimations and if it’s unclear with the estimate until the end of the day after reviewing the goal and code in detail – compete for refinement sessions asap otherwise the sprint is compromised.
- If any action items are defined during daily meetings, summarize them in the calendar meeting description and resend
- Check any unassigned work items, after all the sprint work items have been estimated to eliminate leftovers and only then overview the workload hours for the sprint.
- Prioritize the User stories and move less important or exceeding by hours users’ stories to the next sprints or just back to the backlog, based on their priority.
- Set order of user stories in the sprint list, then the developers will see the list of items as you want them to implement it.
- Discuss it all during the process. Communication is your friend. Most of the mistakes are because of the lack of communication.
As we progress and insert more people into the group shortly, those items that have been written, although they are so simple, will add some additional clarity to the newcomers and allow them to integrate better and quicker into our project and team.
And what are your action items, from your last retro?
Share it with us here at grekai.wordpress.com, comment, and let us know.