Episode 3: Setup & kick-off
There are several proven techniques for creating the initial backlog out of an idea, such as: vision box (Img1) or impact map (here’s one example of how to create one). They will allow you to expand the definition of your initial product vision and convert it to a list of user stories or epics (very big user stories). While I do believe that the entire team should be involved in working on the product backlog, it’s a responsibility of the Product Owner to define the initial backlog in collaboration with the stakeholders; this is needed to give the team a sense of direction. Having done that, you should end up with a backlog of mostly high-level epics, that in the next steps will need to be refined together with the team.
Let’s get to the team then…
The Scrum Guide states that a development team should consist of 3 to 9 members (although there is a popular theory that 7 +/- 2 is optimal, however not exceeding 9 is key). That team should have all the necessary competences to deliver a potentially releasable Product Increment; it could be much easier to build such a team having a rough draft of the backlog and a valid product vision – don’t you think? When talking about IT products, the team would most commonly consist of several developers (frontend and backend depending on product needs), UI/UX designers, IT analysts and QA engineers. The ratio of the first three groups depends on the product: you may not need any frontend nor UI/UX specialists if the product is strictly backend. At the same time, you may not need any IT analysts if the product does not require a complex IT design (in such cases the responsibility falls onto the Development Team and the Product Owner); to give you an example, I have worked with a customer on the native mobile application (iOS/Android) technologies, where the requirements were embedded in detailed user stories by the PO and refined together with the dev team until ready for sprint planning – and that worked fine! One thing I would recommend however, is having not 1 but 2 QA engineers on the team. That is because of two reasons: firstly, in an immature team the QA is often a bottleneck and secondly, a single point of failure. As the team will mature with time, a scrum master should encourage self-development on a cross-functional level within the team, which should make it less prone to external factors, such as: sick leaves for example. However, at the beginning it’s important to pay attention to the balance of competences within the team, every sprint, every step of the way towards the goal. I suppose working with a team of full-stack developers would make this much easier, but then again in my experience, such setup was not so common.
One note at this point: if you have the comfort of restructuring teams from existing ones, then conduct team-building workshops and let the team(s) establish themselves. They will be much more productive, responsible and grateful if they get the chance to volunteer rather than to be assigned together. Obviously make some assumptions up-front to what the team competences must be, as well as other pre-requisites like seniority balance or on/off site factors.
Every new team will need time to ramp-up! It doesn’t matter if it’s a bunch of complete strangers or some people who have partially worked together before. The stabilization period may vary depending on the circumstances. While for a completely new team, a lot of effort would need to be put into team building and synchronization activities, a team that has at least partially worked together before may (but does not have to!) have some old habits, which are not necessarily aligned with an agile mindset This might require “restarting” the team and can be as time consuming as building new team relationships from scratch.
Three simple activities, that I have found very useful for starting a new team are:
• Building Personal Maps
• Establishing a Team Working Agreement and a Team Motto
• Creating a Reference Story Estimation set.
The first one comes from Management 3.0; it helps to break the ice and let the team have a kick-start in getting to know each other. The second allows to establish the rules for working together within the whole Scrum team (Scrum Master and Product Owner included) and to define the team by means of a Motto; sort of like an under-title for the team’s name (which, by the way, should be picked by the team itself as well). The last one builds a foundation to the common understanding of complexity within the team, which is very important since at the beginning the team will probably spend a lot of time gaining consensus on estimating complexity and effort of backlog items. Afterwards, the team should be off to a much better start.
Now that we have the initial backlog and the team, which is thrilled to just kick things off, we need to start somehow. That can be difficult since most of the backlog items are not ready to be planned, are not refined, are lacking team understanding. In addition, it’s highly probable that the team will recommend new items to be added to the backlog for setting up their working environment, conducting research on vague topics (Spikes) or just gaining knowledge in areas of the backlog where they still might be lacking some competences.
Here’s what can be done:
• The Product Owner should collaborate with the dev team to introduce their most important recommendations as new items to the top of the backlog and refine those items as much as possible to make them ready for a sprint (environments, tools, knowledge)
• Start Sprint 0 as soon as it is possible with at least the above-mentioned items and continue refinement on next, highest prioritized areas of the backlog throughout the sprint, as recommended by the Scrum Guide (up to 10% of the team’s capacity; if it’s a bit more at the beginning that should be also fine)
• Establish an agreement on the MVP between the Product Owner and Development Team; the PO should communicate his expectations that represent the Stakeholders’ needs in terms of timeline and scope, but the agreement should be negotiated with the team based on their best knowledge of the product backlog at the given moment
• Support the teams’ understanding of the backlog high-level and build an initial effort projection for the PO by conducting relative estimation sessions (bucket estimation, affinity sizing); this will allow for “guessing” the project timeline at the given moment, which should become more accurate with every completed sprint
I’m confident that following these recommendations will help you get off to a better start and avoid some common pitfalls, however, always remember that Scrum is founded on empiricism and everyone should be learning from their experience – Inspect and Adapt in a Transparent way.
for more information contact us
Read more about our solutions
This series of articles is my attempt to share with you some of my thoughts, experiences and practices, which I have gained during the last 5 years while working agile. It would be a personal achievement and a huge satisfaction for me, if it would help some of you to improve your work and/or project in any way. I am always open to your feedback and I welcome any discussion.
Have you ever wondered why Scrum? What’s the overall reason behind Scrum and Agile becoming a trend in product delivery, and a popular way of working? Why are so many companies, big and small, starting to focus more and more on a completely different approach to not only create products but to change their whole organizational culture? Let’s give that a thought…
One question regarding Scrum that comes up quite often, whether it’s during an academic discussion with my “colleagues from the industry” or just some theoretical pondering of my own, is: if you had to eliminate 1 Scrum event – which one would it be?
Obviously, once you are confident with having a proper Scrum Team in an agile environment, you might want to take it further and expand – and why wouldn’t you? Scaling your Scrum setup can help you get more stuff done and at the same time enforce the agile culture in your project and organization.
A common question that any manager or executive might ask (or be asked for that matter) is: “How well is the team doing?”. That’s a fair question which leads us to the 3rd pillar of Scrum: Transparency.