After the planning phase, we sent the proposal and the contract to the client for review. In the proposal, we include some information about the future product, how the design and development will be done, what tools, frameworks, and languages we will use, our pricing model, and other additional information as needed.

As we've mentioned earlier, we use the Scrum framework to manage our design and development processes. One important aspect of Scrum — the backlog — was described in the Planning section. Another is how the product is made and delivered.

We design and develop in so-called "sprints" - fixed units of time, at the end of which the client receives a working product. These sprints can last from one week to one or two months as necessary, but we prefer one or two-week sprints, depending on the project. Before beginning a sprint, we schedule a meeting with the client to decide on what user stories will be done during that sprint. In this meeting, we discuss the details of the selected user stories, add so-called "acceptance criteria", provide a better estimate, and add additional information to them. We also attempt splitting the user stories to have smaller pieces of work that can be completed faster and estimated better.

Acceptance criteria for each user story in the sprint are discussed with the client and agreed upon before starting the sprint. These acceptance criteria will then be used to validate the story at the end of the sprint so that there will be no surprises on both sides. If at the end of the sprint, the client decides that some user story is not exactly like they wanted - a new user story can be created and worked on in the next sprint. But if the story under question meets the acceptance criteria, previously agreed upon by both sides, it should be accepted as completed. Another situation is if the story doesn't meet the specified criteria. In this case, we determine the issue that caused the story to fail the deadline and determine our next steps. If the client wants the user story to be done — this story will "leak" into the next sprint, or will be dropped if there are more important stories to work on. "Leaking" stories are generally not good, but it sometimes happens, due to different technical or organizational challenges that the person doing this story faces. These could range from waiting for the client to respond to an email or employee getting sick, to encountering different technical obstacles that were not accounted for during the planning (and thus having a lower estimate), having infrastructure outages, or other high priority issues or bugs interfering with normal sprint flow.

The stories that are added to the sprint are visible on the sprint board, which should be available for the client to see, track progress, work, and comment on issues. This makes the whole process more transparent and hopefully help the client feel more secure working with us and to build trust.

At the end of each sprint, we schedule another meeting with the client — this time it is the meeting they usually want to see — the sprint demo. In this meeting, we demonstrate the work that has been done during the sprint, check the user stories against the acceptance criteria, mark them as completed (or not, if the criteria were not met), and gather feedback from the client. Each sprint demo is like a small product lunch — the features developed during the sprint should be production-ready and be deployable (or deployed already) as soon as requested.

There is another short meeting the client can attend - a sprint retrospective. During this meeting, the whole team sits together and discusses the sprint in general, what went right, what went wrong, and what can be improved. The client can also contribute to the retrospective by participating in the discussion so that we can take into account their wishes and preferences. At the end of the meeting, we pick usually one or two pain points by voting and act on them during the next spring. 

These are the main strengths of Scrum, in our opinion — having production-ready software as soon as possible and having the client always in the loop. After all - openness and focus are two of the core values of Scrum.