A sprint for “Software developer”

We all have read “Writing software is an art”. We often hear the terms Agile, Scrum and Sprint. A sprint is usually time boxed to 2 weeks to ship an incremental change to a product. Writing code is fraction only and others go unnoticed, like, Understanding Requirements, Collaboration, Communication, Sprint ceremonies and yet having unplanned activities. Add comments if I missed any…

Understanding requirements

Requirements are discussed as a part of various sprint ceremonies where a developer have to participate. “Quarterly Planning” to grasp bigger picture. “Backlog refinement” at micro level — what are the tasks, dependencies and challenges. “Planning Poker” efforts/estimation it take to deliver the feature. “Sprint planning” committing what can be delivered. And remember, all this happens in consensus with team.

Delivering feature

Delivering working code is fundamental expectations from a developer. Most of us know this as writing Application Code, testing.

Application code,

Title says it all. I am skipping on practices — clean code, secure code, API first and other jargons here. I will cover this into another article.

Testing

Writing test code for the feature is expected to be delivered in the same sprint whether the team adopts TDD or BDD or both. Testing typical involves writing “unit test” to test individual functions, mocking of third party API calls, end-to-end testing.

Shipping Feature

From “it works on my local”, is it time to get it reviewed by other team members for logic, efficiency, clean code standards in a feature branch. Each feature branch requires a build (which does compilation, static code analysis, vulnerability scan, unit test coverage checks in its CI phase) and post merge build cycle starts again and get deployed. Which is where integration testing and QA will perform their testing. A feature is considered reviewable by a product owner only when it is deployed to integration environment.

Demo-ing

A feature shipped to an integration environment is an entry-point for a product owner to evaluate work done by developer against what was expected. A demo is ideally per feature demo presented (often recorded as a back up plan) to explain the product owner what he has done and how the feature is working, highlight any scope creep, limitation and edge cases identified during the entire development phase. At times it may require to stretch an extra mile to meet the ad-hoc enhancement.

Collaboration

Collaboration is key to a success and is no exception for a developer in a sprint. As a developer you need to collaborate within team — product owners to get the requirements clarified before start of the sprint and validated during sprint reviews, other developers, QA, DevOps.

Cross team collaboration — involves upstream, downstream, DBAs, release governance, change approval board and be aware of compliance and regulations well.

Communication

“Communication (a.k.a interactions) over processes” is agile manifesto. This is usually internal communication within team. Daily stand ups on reporting the progress of the feature, highlighting any blockers, challenges faced and discussing alternative plans to mitigate the risks.

Sprint Ceremonies

Sprint ceremonies Planning, Backlog Refinement (also depending on developers may have internal technical backlog assessment), Sprint reviews, Sprint retrospectives, Daily stand-ups, take considerable amount of time in a sprint and usually varies from 15 to 20% of time.

The unplanned ones

Beyond the planned activities above, a developer usually get pulled into random meetings, slack chats, attending company town halls, googling (now ChatGPTing), learning and upgrading one-self, 1-on-1s and be on toes when an issue is reported in production. I am discounting discussion on individual life here.

Conclusion

By now, you already have a fair grasp on what a sprint means for a developer, repeating every two weeks. Hence being a developer isn’t an artisan but an actual pilot of organisation.