Other Sprint Activities - a guide
I'm managing a project that has graduate developers on the team. They are not yet very familiar with some of the background activities that contribute to a good delivery. This guide was knocked up to give them a starting point to think about what else they can do when they aren't coding on a user story. I’m focussing on tech stuff here and with an assumption that we’re doing Scrum or something pretty close to it.
What if there are no stories in the sprint (either in progress or in the sprint backlog) that I can contribute to. What can I do?
- Really, check with the people who have stories in progress. Things may have moved on. They may have changed their mind. Let them know they can lean on you for any assistance. Whats the test coverage looking like for the in-flight stuff? Get them to check it in if they have not already done so. Don’t be a dick about it though - you’re not chasing progress.
- Talk to your product owner. They may have something to suggest. It may be that they don ‘t have an up to date view of your teams’ progress this sprint. They may want your help fleshing out something in the backlog.
- Use the product like a user. Find defects. Log them.
- Functionality.
- Style inconsistencies.
- Typos.
- Security.
- Performance. Not necessarily in that order.
- Do something to improve the productivity of the team. For example if there’s a lot of test setup that is repeated, is there something you can do to simplify things even for a single test module? UI tests in particular can be looked at.
- Think about those areas of the product that are most likely to fail (hint: calls to external systems!) and review the flow through your application that the data takes on its way to the users’ screen. Is it robust and secure enough?
- Investigate some tech that may be useful in the future on this or related projects. There’s a lightning talk in there so not only do you get to learn, but so do your colleagues when you present it.
- Refactoring and test coverage. This comes with a helping of ‘understand your codebase’. Identify the modules with the lowest test coverage and review them. Refactor if you need to.
- Which modules have seen the most commits? Why?
- Which modules have the most code? Which methods have the most complexity? Can you see that easily (find out how to get it).
- The least? Have a look at these and see if they need some attention.
- How up to date are all those web dependencies? Can you usefully update them without getting into the weeds?
- Linting. Assuming that your code meets current levels, can you increase the tightness of the linting rules without having to modify dozens of files? Can you identify a small change to improve a single module, even if you're not going to turn on that rule just yet?
- Whats the state of play regarding project documentation? Are there notes covering
- How to build
- How to deploy
- How to roll back a duff deploy.
- How is the Source code control system (Git) looking? Are there lots of old branches? Do they relate to pull requests?
- How about Pull Requests? Are there any Open ones you can do something with? Review the code to see of there’s anything to learn. Can you do something to get the oldest ones merged?
- Learning.
- Review your training plan. Do something on it. Log it, along with a short summary what you covered.
- What's The Hotness at work? At the moment there’s a lot of buzz regarding Python, and AI as well.