Everyone working in software development should be familiar with the following situations: your PM sets a wrong deadline for task execution without asking the team or ignoring team estimations, the client goes aggro when you deliver a task because he asked for something different, you’re forced to attend every single meeting even if it’s completely useless for you, your team lead starts blame-shifting and finger-pointing because the milestone wasn’t delivered on time, etc. In most cases, it happens due to the lack of discipline and incorrent sprint planning.
This article aims to give you an example of the basic workflow of a single sprint (let’s call it Sprint N) and answer such questions as how to plan a sprint, what actions should be performed, what artifacts should be collected and why each of them is crucial for the project success. It can be useful for novice software developers, small teams with no PMs or teams where PM and team lead roles are merged.
Sprint N-1 (which is not quite a sprint yet): Preparations
Before starting sprint N, your team should be engaged in preparatory work:
- Reduce/eliminate any possible misunderstanding of the project goals, deadlines, etc.;
- Test hypotheses and do end-user research;
- Create sprint workflows and visualize them;
- Get the approval of all stakeholders, and more.
The output: a set of artifacts and data that match your Definition Of Ready checklist (that will be described in detail below).
If you want to improve the interaction between coders and other participants of the development process (e.g., testers, system administrators, etc.), it will be useful to introduce and explain the essential functions and roles of each of the participants. There are enough introverts among software developers who do not like to be disrupted at work, but they also need to understand how others work to avoid miscommunication and interruptions down the road.
Here we go.
Start of Sprint N-1
OKR, KPI, and stakeholder requirements are internal and external guidelines that show a direction for your entire software development.
Sprint N goals
Your sprint goals depend on your input conditions, development methodology, parameters, and anticipated results.
The purpose of a sprint is to motivate the team, explain the meaning of their activities, and set key performance indicators.
Any software development team needs motivation so that development does not turn into an endless series of meaningless and unclear tasks. In companies where software development is not the core business function, there is often a problem that software teams aren’t appreciated appropriately due to the lack of their work transparency, which results in huge drops in team morale. Therefore, any software engineering team needs to have transparent and clear goals set and all workflows visualized.
Backlog grooming (aka backlog refinement) takes place when the product owner (PO) or PM and the whole team sit together to review items on the backlog, make sure it only contains the appropriate items, set priorities, and make sure items at the top of the backlog are ready for delivery.
Sprint N-1 planning is a meeting between PO/PM and all team members where they analyze, evaluate, and prioritize all tasks in the upcoming sprint. It helps simplify your resource planning and management significantly.
The Output: Sprint N backlog.
Test development
It depends on your style of development and whether or not your team has a dedicated tester/QA engineer.
The goal is to develop test cases for checking the code’s operability, clarity, etc.
I suggest you consider two options:
- If there are no testers on your dev team, let your developers create test cases. In this case, this activity should be performed within tasks development in sprint N. Based on my own experience, such an approach improves the overall quality of your code.
- If there are testers in your team, you may use the approach of creating test cases before writing the code.
Development of Use Cases is a detailed study of interaction scenarios and results within the task.
The goal is to describe interaction scenarios of the task with text or diagrams to improve understanding of the problem by all stakeholders.
The output: well-crafted test cases and prototypes.
Lack of test cases leads to a lack of understanding of what is required of the task.
Wireframing, mockups, and prototyping comprise one iterative process for creating interface design and visualizations. Starting with the simplest and cheapest option, user/stakeholder testing is performed to see if the proposed solution meets the expectations. Visual testing proves very useful in reducing the variability of text description and is very inexpensive compared to coding. Today, there’s a trend of embedding visual testing in software product development and even developing a new methodology with its processes, artifacts, and schedules based on it.
Wireframing is a rough sketch of interface elements. It can be done manually with a pen and paper or digitally with a myriad of free and paid tools like Balsamiq, Moqups, Justinmind, Fluid.UI, and many more.
It enables fast and low-cost testing of the task at hand and fast approval by stakeholders. The additional visualization dramatically improves the overall perception of the product and its goals.
If there’s no wireframing, you’re at risk of facing discrepancies in the understanding of what is really being created as well as overheads.
If your PO or key stakeholders disapprove of your wireframes, always ask them to document it and demand that they send you a formal letter of disapproval in writing to avoid “that’s not what I asked for” situations.
The output: approved draft wireframes.
Mockups are the second step in your interface visualization. Unlike wireframes, mockups provide as many details as possible. Again, if you want to omit this step, you’ll risk paying through the nose for change requests when your project is halfway through.
The output: approved mockups and layout,
Prototyping is the third step in your interface visualization. In addition to the high level of visualization details, it helps demonstrate every single user interaction with your digital product.
DoReady (Definition of Ready) is a working agreement between the team and the product owner on what task readiness means. It’s a checklist that is used to verify whether all of the required artifacts are in place to ensure its acceptance into development and production.
If you don’t agree on DoReady, brace yourself for the following commentary from your developer: “The task is almost ready, it’s about 90% complete!” In my opinion, it’s the most important document that enables a great symbiosis between your team members with different roles and reduces/eliminates conflicts and blame-shifting in the future.
Now when the preparatory Sprint N-1 is done, let’s move on to Sprint N.
Sprint N: start of development
Sprint N planning is a meeting where the team selects, evaluates, prioritizes, and decomposes tasks based on Sprint N goals and scope. Depending on the average speed of the team’s work, a certain amount of tasks is set.
It is the central meeting to ensure everyone on the team understands the current sprint goals and his/her role and level of contribution. At this stage, developers finally estimate the cost of each task.
If there’s no sprint planning, you’re at risk of facing havoc, as there’ll be no clarity as to task goals and personal involvement.
The output: sprint N backlog.
Depending on the size and speed of your team, you may want to dedicate 70%-80% of the sprint time to completing sprint-related tasks and 20%-30% on bug fixing, tech debt elimination and unexpected issues resolution.
Decomposition and tasks assignment
The point is that your PM or team lead decomposes the sprint tasks into subtasks for a maximum of 1 day (maximum 2). Sab-tasks are assigned to developers depending on their specialization, strengths, and/or preferences.
The team’s participation in the process determines whether the developers will receive interesting tasks that contribute to their development.
The output: detailization of all sub-tasks in Sprint N backlog.
A daily meeting is a short meeting of the entire development team. Every day, developers have to synchronize with each other to know who did what, what they plan to do today, and what problems prevent them from doing the task.
If you work without daily synch meetings, you’re at risk of facing chaos as developers will not know who does what. As such, you may encounter serious execution issues.
The output: burndown chart reflecting the progress.
In my opinion, one of the crucial things to be introduced and instilled within every software project team is the discipline! As mentioned above, many coders and engineers are introverts who hate to be distracted in the work process, aren’t very open to communication and hate wasting time in meetings. Yet, there should be formal rules to keep your team disciplined, and daily standup or SCRUM is one of such rules.
However, if your software team works together like a well-oiled machine, your team members communicate with each other in Slack or similar messengers on a regular basis and share knowledge and issues, you can reduce the number of daily standups from five to just one or two, but I wouldn’t recommend you skip them entirely.
Identification of showstoppers is a direct result of your daily meetings. After your developers have voiced issues with the implementation of the tasks, the whole team gathers to discuss showstoppers and bumps in the road to successful task completion and try to find the solution together.
Commits/Code Review is the verification of code by other team members.
The point is that 1-2 team members should see the new code written by their colleague(s) and approve the quality, style, etc. Otherwise, you risk delivering code that’s hard to read, understand, and maintain. Clean code-driven development is at the heart of every successful software dev project!
Feel free to involve people of different qualifications and seniority levels in your code review. It’s a very useful exercise for all levels including your junior dev talent.
Deploy to the development server
Any implementation of the task can be deployed to a specific development environment where any stakeholder can test and pre-approve the work done.
Failure to do so can result in the failed demo (when the task presented doesn’t work as expected).
The output: Informal approval of the completed task.
Definition of Done is pretty similar to the Definition of Ready. It is a checklist of principles by which PM/PO accepts the performed tasks.
It is created by the development team together with PM/PO to make the work acceptance parameters predictable. Everybody knows what it means when the task is labeled as done, so it adds transparency to your project delivery.
Without clear criteria, the tasks can be buried in the backlog for ages without getting approved and accepted.
It’s a very important document that confirms all acceptance criteria set by the PM/PO, and that’s approved by both stakeholders and the development team. It provides the following benefits to project developers:
- PO/PM doesn’t use their power to lobby a decision (e.g., choice of methodology or tools) or solution to be built;
- All tasks are 100% completed, not 90% or even 99%;
- If the task doesn’t comply with your DoDone, it’s not considered accepted and moves to the next sprint.
Review and demo of the product’s increment is a formal meeting where developers demonstrate to stakeholders that the sprint goal has been reached.
The point is that developers demonstrate a workable product increment and PM/PO formally checks it against task evaluation criteria and DoD compliance. Stakeholders decide whether the new increment of the product meets the Sprint goal.
The absence of a formal demonstration and task acceptance reduces the value of your acceptance criteria and the overall quality of task execution.
The output: The team’s work is complete. Stakeholders decide whether or not the next sprint will be done at all.
Demonstration of the completed task by developers is more useful and understandable than the impersonal provision of new functionality to the stakeholder for self-assessment.
Gathering feedback is a continuation of the Review and Demo meeting.
The point is that having all stakeholders, the team and the product itself in one place allows for informal communication, gathering ideas, suggestions, etc.
The output: new data, feedback loops.
Sprint retrospective is a formal meeting where the development team and PM/PO discuss what was good and what went wrong in the latest sprint. It helps identify the most and least effective methods, make informed conclusions, and avoid similar issues in the next sprint.
The output: process experiment plan.
Besides the banal discussion of problems and how to solve them, I would like to pay attention to the “Process Experiment Plan”. You should not treat the recorded processes as cut out in stone – unchanged and constant. If you add new things – test them, if you do not like them – remove them.
End of Sprint N
Sprint N+1. Deploy a new increment to the production server.
Because most sprints are weekly and end at the end of the working week, increment deployment to production server happens typically in the next sprint to avoid any force majeure issues during the weekend.
Conclusion
Careful sprint planning, as well as formal and informal activities within each sprint, ensures and instills discipline within your project development team, foster clean code and documentation-driven development, add flexibility to process management, and respond to emerging issues promptly. All of this will help you complete your project on time, to your budget, and without any quality compromise.
