Ok. Now you're a product developer. What's next? I will talk about the development cycle from the point of view from the inside.
Part 1. Working out the backlog.
Work on the task begins much earlier than the programmer. Before taking the task to the sprint, the team clarifies all the issues.
📌 - Asks the product owner for acceptance criteria;
📌 - Conducts a pre-assessment: how much money the task will bring, and how much it will cost in development;
📌 - Works through all architectural aspects;
Согласов-Coordinates future changes with all external stakeholders;
📌 - Understands how it will conduct post-pricing;
📌 - Decides which feature health monitoring is needed after the sprint;
📌 - Creates a top-level sprint plan.
This is not an exhaustive list, I will show our Definition of Ready for sprint (DoR) later.
Part 2. Sprint planning
A sprint starts with planning. The better the team prepares the task for the sprint, the faster and easier the planning will be. The better the planning, the more likely it is that we will not deviate from the plan in the sprint. If you go according to plan in the sprint, then with a high probability the output will be what we expected.
For saving time and make our estimations more accurate we use Chpokify's Planning Poker online tool. We decompose the preliminary plan into tasks no larger than a day. Participants take on tasks and distribute them by day. At the same time, it is advisable to leave time for the development of the backlog and for improving processes and engineering practices.
After planning, the team goes to work. The work can be either paired or individual. But everyone understands the contribution of their individual work to the overall goal of the sprint.
The overall goal is, in my opinion, the main difference between a team and a working group. The end of planning will mark another opportunity for us to do something useful. We are not fanatics, but at the end of the planning, we jokingly congratulate each other on the start of a new sprint 🚀
Part 3. Working in a sprint
Sometimes work groups perform a ritual called stand-up. They stand in the aisle and take turns telling us who did what yesterday and what they plan to do today. Just as the working group has no common goal, so this ritual has no meaning.
Every morning, the team meets to answer one question: "Is everything going according to plan?" Even with perfect planning, a crash can happen. In this case, you need to either cut off some of the work, or use the backup time. If it was pawned, of course. Sitting in the evenings is definitely not the way to success. This is the path to burnout. It is better to see the deviation from the plan as early as possible and agree with the product owner about cutting off some acceptance criteria.
If everything goes according to plan, the release happens in the beginning or middle of the second week. This makes it possible to collect the first feedback from the universe by the end of the sprint. Feedback can be, for example, metrics or interviews with users.
This feedback can be collected by the same developer who just finished writing the code yesterday.
I will speak for myself: through collecting feedback, I understand the real usefulness of this code.
Part 4. Sprint review
At the end of the sprint, all product teams meet. Someone calls this event a Demo. We used to have a demo too. But at some point, we changed the format of the meeting and now we are reviewing the sprint.
The demo is a useful event to make the work of related teams more transparent. It allows you to see what features are born in the product, understand what components are in the product and how they can be reused.
In addition to the demonstration, the sprint review also involves collecting feedback. Feedback can come from colleagues. Or from live users. On the sprint review, you can immediately voice a preliminary post-evaluation of the feature.
In my opinion, the sprint review brings more value to both the product and the developers. It gives you the opportunity to see the benefits from yourself and colleagues, get feedback, identify risks and park new hypotheses in the backlog.
