Meetings

There is a movement to eliminate or minimize meetings (and meeting duration) currently ablaze on social media. But independent of this movement, most teams still have scheduled or predictable conversations that are part of most sprints/quarters/cadences. These can be sprint-related (planning, scoping, retrospectives), architectural planning to unify a direction, customer discussions/emails, reviews, company wide meetings etc. These all take time. And often, there is prep-work for each meeting. 

All of these interactions should be documented in tickets (JIRA, Gituhub, etc). If there is an Epic for a new feature, there should be a Story that is a planning meeting. And, there should be  another ticket for any prep work or research in preparation for that meeting; maybe a 3rd ticket to record meeting notes (or maybe one story with 3 tasks – the construct doesn’t matter). Just as the “trendy” fads for meetings (discussion of 30 minute meetings only, or no-slides, or send notes before hand) are capturing aspects OF those meetings, so should any ticket. If the meeting is 30 minutes, make sure the points for the meeting is corresponding. Prep work before hand/after should also have a ticket. And if that ticket wasn’t created at sprint planning, add it after – so that the sprint DOES REFLECT what actually happened  (and maybe why things ran over becomes clear). Consider adding a TAG for tickets made after the sprint started, to capture unexpected additions (not to assign blame but to uncover where work is coming from to make future predictions better).

People often leave these out as they feel secondary to your “real work” or because the point/hour system make them seem unimportant and therefore “invisible” in the broader scale of points.  But don’t let that fool you. These tickets don’t need to be large, or have high hours/points – but pretending they don’t exist is a big problem because that impacts productivity. Even company wide “all-hands” or an “off-site” takes time away. 

We are not advocating for MORE meetings or LESS all-hands…. But if your velocity is 65 points (or whatever your unit of measure happens to be), then if there is an all-day meeting or if monday is your retrospective/planning day, make sure you account for the time spent on those activities and to any foreseeable meetings (e.g. a design review, or architecture designing) that are part of the tasks assigned to a given sprint.

Debt

Deadlines exist and they are an inevitable like death and taxes. While we all would love to design and build n the most robust solution,sometimes we must use metaphorical duct-tape and spit to get out the door. These stop-gap measures lead to accrued technical-debt or design-debt and this is often forgotten once the deadline is met. To prevent the debt from getting out of control,  for every major release (of a product or feature) we create an epic called ABC-Debt. Every story in this epic is created when someone makes a short cut such that we all remember to refactoring and refinement later on. 

Therefore, before that team works on feature 2.0, we make sure to take technical debt off the backlog. If a team-member leaves (because there are other good jobs) a record of each  limitation exists within an annotated ticket and let the team know about blockers This isn’t perfect, and sometimes things are missed – but without recording your debt, you won’t know where there might be a hidden bomb in your product that could easily turn the next great feature from a 4 week project to a 6 month quagmire.

Project Management and Backlog Grooming

Someone always has to clean up the mess around the house. And every sprint the team makes a mess in the backlog. And just like the dishes, if you leave them dirty for too long they develop intelligence, invent fire, and start working against you.  Controlling that chaos is something that must happen every sprint.

In theory, every team has a project manager whose sole job is to run sprints, manage the backlog, etc. In theory, that person is using sprints to manage their own time as well. But we have found that most teams lack a project manager, leaving this work for the team leaders, so this tip applies to team leads as well. Set aside time for grooming every week (minor upkeeping) and a larger task every quarter (for a really deep clean). The Project-manager/team-lead will see things that slipped through fingers, find un-finished loose ends, and most importantly, keep abreast of all of the work your team HAS accomplished.

To validate that this clean-up has occurred (and wasn’t just ignored or paid lip service) ensure accountability. Team-leads/Project-Managers should report the current roadmap/schedule/delays to the VP of Product and/or Engineering at the end of every sprint. And at the end of each quarter, this should be reported to the CEO/GM. This hard-accounting is vital visibility that leadership needs to make decisions, and assures that that when the CEO says “hey when is X coming out” that prep work was (at worst) done 7 days ago, and is ready to surface right away (instead of hours of scrambling to answer a seemingly simple question).

Documentation

We were all taught in school to document our code and designs. Use good variable/layer names. Be consistent, and if anything, document first code/design after. Then we got to the real world and getting products done is the primary  task. But 9, 12, 18 months later (or if you are successful 5-10 years later), the team is unlikely to remember how a random function works (or the motivation behind a given design). That documented/written personal and/or group knowledge is invaluable and allows a team  to make changes faster and fix bugs more easily s even if the original author is no longer part of the team .

I know justifying documentation isn’t the point of this article, but seeing documentation fall by the wayside because it “was not a priority,” simply cannot be an excuse. When you are creating your projects, make sure to add some stories for documentation. Explicitly set aside time to annotate and explain what you created. Then when sprint planning occurs, or leadership wants to know how long something will take – you can look at the epic and say “this is a 2 sprint epic” and know that at the end of that sprint, it will be working AND be able to be supported.

In other words, start looking at sprint management as team management. It should capture everything your team must do to build and support your product – now and in the future.