Suppose you have an idea for a marketplace in your head. You woke up in the morning and thought: it would be nice to create a service for booking sports grounds. A service that would allow you to book both a venue for mini-football and a course for playing golf. Having thought a little, you decided: why not?
Indeed, why not? A professional Project Manager can finalize even a habitat idea and turn it into a profitable startup. This specialist joins the project at the very beginning, taking into account that the project undergoes 2 stages — the project analysis and the implementation itself.
At the first stage, the product backlog is created — it is a list of tasks that facilitates implementing the idea from a technical point of view. The second block is about realization — design, outline, and development of the marketplace.
From the communication point of view, these stages are quite different:
- The project analysis assumes chaotic communication, meetings and Skype conversations are specified in advance, no scheduled events;
- The project implementation — communication is more regular and well-planned, the exact time of meetings is set, the customer receives a report at the end of each session, and moreover he can participate in discussions on a daily basis.
For better understanding, let's look at each stage in more detail.
Workshops at the stage of the project analysis
There is nothing tough to work around at the beginning — first adding the client as a contact on Skype. We then speak with the client, share information about one another, and when we understand that we have the same vision, we schedule a series of workshops for analyzing the project.
Workshop 1: Define epics and priority
On the first workshop, our task is to define epics — big functionalities that we need but don't know how to implement yet. For example, for the marketplace on renting sports grounds, the following stuff is needed:
- A list of sports grounds (for different sport types and locations),
- A booking function,
- Availability of payment systems,
- User profiles,
- The profiles of providers.
These big “kings” will split into a number of small tasks. But for now, it's important to understand only the key targets and their priorities. What should be done first?
To run the MVP and boost traffic, creating a catalog of marketplaces would be enough. Then the profiles of providers and payment functionality can be developed (without a booking function yet), and then everything else can be added.
There are different cases: one is when a client generates a thousand ideas by himself and then we choose the most important idea together or vice versa when the client works with the team to help generate ideas because he hasn’t initially got one in mind himself. There should not be more than 20 epics, and it's crucial to realize what should come first and what should come after.
Workshop 2: From epics to user stories
Now we work on details. For example, the epic about the catalog presumes creating the search.
We are writing possible user stories for it (“As a user, I want to choose a basketball ground in my city/district…”). Having them as a starting point, we are generating more specific tasks.
For example, to make the search function work, it's necessary to:
- Create pages with the search results,
- Publish information about sports venue, the descriptions,
- Implement the search by location (relevant search),
- Add filters by attributes (size and the type of sports venue, sport types, etc.)
After the discussion, we are having a time out. As a Project Manager, I review the work that has been done and discuss the pitfalls along with the team. For instance, why have we planned implementing the search of the ground with filtering by sport types, but have missed filtering by price?
Workshop 3: Finalizing the scope of work
The workshop is the tool for discussions and making conclusions. The final scope of work — all the tasks of the project — is generated after this workshop. Now I have the whole picture and can estimate and inform the client of how much time and money is needed.
Workshop 4: Discussing the estimation results
It is the final discussion of the estimation results. At this stage it becomes clear how quickly we can implement the project and how much it will cost. We resolve the tasks on planning: whether it makes sense to change priorities, decline this or that functionality because of its high cost, etc. Once everything is agreed upon it's time to get to work.
In addition to the project tasks, at the analysis stage, we stipulate a format of the future work. Often the customer hires a team of up to 3 developers, and a Project Manager plays several roles at the same time - a Business Analyst, a Scrum Master (the one who is responsible for planning), and a Proxy Product Owner — a person, who is involved in all the business processes and can give answers on behalf of the customer.
This format of work is suitable for startups as they don't need a big team and, as a rule, they cannot afford hiring each specialist as an individual person. Ideally, a Product Owner, a Scrum Master, and Business Analyst are all different people.
Project implementation according to Scrum
In project work we stick to 2 Agile methodologies — Scrum (suitable at the development stage) and Kanban (suitable at the stage of service support and maintenance).
I will speak about the first one and the way it facilitates in launching a project from scratch.
The Scrum methodology assumes approaching the results in short sprints - jumps, in order to release the working product as fast as possible. A single sprint lasts 2 weeks and lets us finish a logical part of work. At the end of the sprint, we report about its implementation.
This is how it works:
- Planning of the release (up to 4 hours) — at the beginning of the sprint, we plan and discuss the tasks for the next two weeks,
- Daily stand-ups (10 minutes each) — every morning the team's work is synchronized and the plans for the day are updated,
- Sprint retrospective meetings (up to 4 hours) — we analyze the results of the most recent completed period.
Customers are added to the project management system Jira and are notified about all the changes. However, I do not recommend analyzing an uncompleted project. At the end of the 2-week period we will show the final result.
To make the project development more effective each team member can directly address the customer for clarifications. As a rule, the kind of questions usually asked consists of how should a calendar work and what should happen after a mouse click.
What if the customer changes the tasks?
It's not recommended to make changes within the sprint, nevertheless, there can be such cases. For example, the customer wanted a video to be displayed on the site instead of a picture of the sports ground.
If the change does not impact the general scope of work, we implement it within this sprint. If it does we postpone the task, divide it into parts or replace it with another one that can be moved ahead.
A Scrum is a collection of flexible project methods that we can always fine tune according to the latest changes. For example, the customer asked us to further to develop the search by grounds/venue option and this task is in the current sprint. But suddenly the search is supposed to be semantic, i.e include different forms of words and ignore grammar mistakes. This change impacts the scope of work and correspondingly, increases the amount of time and money needed. Keep in mind that the scope of work, planning of time and budget are all sides of the same triangle. As one side increases in length, the other two follow.
There is a common problem that occurs when taking on a new task, sometimes you have to decline the one you were working with before and have not yet finished. Therefore I often say that any task can be accomplished, but we care a lot about the result. When the unfinished task is put back on track the total amount of time spent on it appears to be more than if we had just kept working on this task without interruptions.
This is the reason why I recommend to not make more than one change during the sprint. Although, in general, we are not afraid of changes. If the customer decides to change everything in a global sense — create a website on ordering classes with the instructor instead of the marketplace on booking sports grounds — we can implement this. It's just a matter of needing the time to do it.
Communication within the team
All teams take part in all the workshops because:
- They may have another vision,
- A development team should know the long-term perspective of the project development, otherwise there can be many local mistakes.
Let's imagine that we implemented pagination onto the site but then the customer decided to load the catalog information using the scrolling functionality. Or our architecture missed the fact that the project will be scaled to other countries. If the team is aware of such things beforehand the site can be initially developed in a different way. Often it's quite easy to predict the architecture, and further changes will require correcting the existing code.
That's why I insist on the team participating during all the stages of communication:
- High level — workshops (scope, epics, global tasks)
- Middle level — user stories details, sprint planning, retrospectives
- Low level — daily stand-ups, clarification of details (what's the functionality of this button?)
It's important to understand that people perceive information from the perspective of their own experiences. If someone has understood the concept in his own way, he can also implement it using his own method. This is the reasons why we conduct the planning at the beginning of the sprint, in the middle, and at the end of it.
Daily stand-ups help to find out how the team is approaching the task at hand during the sprint: what was done yesterday by each team member, what is going to be done today, and if there is any hinderance to the team’s overall progress.
It's worth saying that only the developers apply Scrum to their work. These specialists have T-shaped skills — they are experts in their area and also have knowledge in close, adjacent ones. For example, a back-end developer understands the front-end code and has some knowledge about its outline, so the team does not lose its velocity when any of its members are absent. That's why graphic and layout designers work as a separate team.
Also, we make sure that each specialist's productivity is different: the design is created within 3 weeks, the outline with this design takes 1 week, the development takes 5 weeks. To work around this disproportionality of time allocation, the design and outline go ahead a bit. The specialists also participate in daily stand-ups, but they usually keep to their schedule.
To help team newbies adapt to the tasks quickly, we prefer written communication to oral. It's a long coding process, and documenting helps when it's necessary to review the history. I suggest creating release notes — documenting what was developed and updated in each release. As the project becomes more and more complex, it's useful to run technical writing — an instruction of how to work with the system.
Preview photo: Martynova.Katie / Depositphotos.com
Header photo: Rawpixel / Depositphotos.com
