Effective habits while working on the backlog

In part 1, I wrote about some healthy habits of engineering teams to facilitate team building and work well with each other. Part 2 was about having some key points in mind during the design phases to effectively collaborate as a team. This article, which is the third of a seven-part series, is about useful habits of Engineering teams while working on the backlog.

I'm not re-iterating Agile methodologies here, and I'm also not claiming to be an expert in Scrum, Kanban, Lean, etc. Take these ramblings as me sharing experiences we had in several projects while applying Agile methodologies and processes in different flavors. Perhaps you also had this experience and can relate, or you know of a better way. In this case, I'm genuinely interested in learning more from you.

It's great to have a process to follow and a framework everyone is experienced in. It doesn't need much onboarding and explanation for the team as a certain baseline already exists regarding collaboration. If the project team hasn't worked with each other before, ideally the differences in perception and expectations are only slight deviations from a specific methodology.

How agile are we?

While Agile processes make a lot of sense and they are proven to work and deliver the right outcome when applied, it is always good to keep the rule number one of the Agile manifesto in mind:

Individuals and interactions?over processes and tools.

If something doesn't work for the team, try out a different or several different approaches to find a better way.

Depending on the project and the teams we worked with, we often used a template for collaboration of how we'd like to work on a project. The template included how we thought to conduct the ceremonies, how we perceived definition of done, quality control when PRs are merged, etc. We summarized it in the Game Plan for the engagement and had more details in the Work Agreement (see Part 2), which we agreed upon as a team in the beginning of a project. This template was adaptable and allowed us to change, learn and improve in every project when working with different teams.

Retrospectives

Retrospectives are a great tool to improve what is not going well and keep or celebrate things that are great to keep in an engagement. Needless to say, Retrospectives are only effective if the feedback is not only heard but also introduces change to how the team collaborates and improvements to the project.?Don't forget to create meaningful action items in the end of a retrospective to make sure that feedback is being incorporated in the next iterations. This could range from improving the description of tasks, having more concise acceptance criteria, having a design discussion before starting implementation, correcting missed dependencies, avoiding breaking the build, or introducing changes in the ceremonies to make the team more effective.

Technical Stories or User Stories?

Often, an actual user story does not necessarily express what needs to be done on the technical side and might entail transforming it in one or more technical stories. One simple change of how a user goes through an order process could mean modifying several parts of a solution. As a team, we found it practical to translate and break?down the User Story into Technical Stories and provide a meaningful description for the team to work on. If your tool allows it, link the Technical Stories to the User Story so that they can get tracked in your reporting accordingly.??

If the scope of a backlog item is too large, the result could be having an engineer work on it for too long and a huge chunk of code to be reviewed by the others. It could also be more difficult to merge, since there could be conflicts due to other team members merging their work in the meantime. It's better to keep them as small as feasible (not as?possible, since there's also a downside to having too small scopes). Too small scopes could mean having to divide the work in many chunks and it could mean more dependencies between the technical stories engineers work on. More dependencies require more time to align each other's work.

Alignment

Sprint planning is a great session to discuss and plan the work ahead. During estimation, individuals in the team can think independently about the effort needed to accomplish a piece of work. By calling out the team members who gave the least and highest estimates, the team can align on their perception of the work and what is needed to get it done. This exercise also flushes out if a technical story is too ambiguous, too complex and requires to be detailed or broken down in more than one technical story.

Regular design review sessions facilitate discussions needed in the team to align tasks if there are dependencies, or clarify how an engineer plans to approach a specific feature. It may be useful for the others to know or give feedback to the approach or design because they have worked on a dependent feature, or have experience with a specific pattern needed for the task. These design sessions could be regular, i.e. once a week at a specific time, or when an engineer calls out that they require to meet with specific people in the team who are relevant for the topic. In our experience, it was good to have both versions. The regular session was a fixed point where everyone was able to present their design and approach, and it informed the others of what they were working on. Some engineers may be reluctant to ask for the time of others and it requires one further step to set-up time for a meeting. If the meeting is already recurring, there's no threshold.??????

Thank you for reading and I'm quite sure that there are more useful habits an engineering team can adopt.?I'd also be delighted to read about habits you found useful during your projects.

Up next

Establishing a baseline for engineering quality?