I've noticed that it's always a good time to go back to basics. So I recently took a quick look at some Scrum framework diagrams. In all of them, with minor variations, we can find:
- A vision
- A product backlog
- A sprint backlog
- Iterative sprints
- Planning meetings
- Daily meetings
- Retrospective meetings
- A potentially shippable product
What I'm going to propose is that we take an in-depth look at these and seek the areas that make you feel completely comfortable about your team. And then, of course, look at the other ones. . . .
The execution process
What I've been seeing is that many teams are completely focused on the, shall I say, execution process. Meaning:
- Having some product backlog items ready to go
- Preparing a sprint backlog with high-priority items (listed in order, for those who prefer that)
- Executing a sprint of fixed duration, typical tasks being development, test, document, and deploy
- Having the daily Scrum meeting
- Finishing with last-day meetings and with the product backlog items deployed in a test environment
And this should not be a complete surprise, as long as ScrumMasters and evangelists are, at least at the beginning, reinforcing the message that the team needs to be focused. It's often noted that the product owner is the responsible for communicating outside team boundaries and the ScrumMaster is there to protect the team from anything coming into the team space.
After a while, though, you'll notice that performing well at the execution-process level is not enough! Maybe you'll get:
- An almost empty product backlog.
- A bunch of functionalities that weren't optimized on performance tests.
- A functionality being implemented by the team only because the customer said during the demo that it would be nice to have.
To avoid erroneous behaviors like these, we need to fill in the gaps.
Mind the gaps
Any team adopting Scrum needs to understand that the Scrum framework flow is a path from the beginning until the end, in which every piece is equally important. Moreover, everyone on the team needs to know clearly the meaning of each piece. The highlights for this article are the vision and the potentially shippable product, with an honorable mention given to the done list.
The vision is the beginning of everything. But not only that — the vision must be the main driver of the project. Therefore:
- It must exist.
- It must be clear.
- It should be shared among everyone on the project: the product owner, ScrumMaster, team, management, customer, and other stakeholders.
- It should be visible in the team workspace.
- It should be the main driver of decisions made during the project.
It would be a good idea to ask the team members individually if they know what the project/product vision is, and if they can describe it. Further, is it clear why they're building that functionality instead of others in the product backlog that have lower priority?
The potentially shippable product
On the opposite side of the flow we have the deliverable, the potentially shippable product (or potentially shippable product increment). What a complex name for a thing that should be simple — the thing you deliver to the customer.
Once again, its meaning must be clear to everyone, and the checklist format seems to work better than long sentences. So, we will have a deliverable to the customer when the following is complete:
- Code written and checked
- Tests done by the team
- Documentation updated on the repository
- Green bar on unit and automatic tests
- Performance tests done and reported delivered to the QA team
- Package built and ready to be installed by the customer
Of course, this is a done list sample. And it must be checked before any delivery to the customer.
At this time, I expect you're guessing the key points about the done list:
- It must exist, built by the team.
- It must be used in every story, every sprint, and every release.
- It should be revisited after a few sprints.
- It should act as the driver to achieve higher-quality levels by the team.
Again, it would be a good idea to ask the team members individually if they know exactly what need to be accomplished to deliver something to the customer. Further, ask when the last time was that he or she used the team done list.
Closing the loop
I hope this review has helped you remember some key points, and that you better understand that the process only works if every single piece of the machine performs well.