How to conduct the excellent refinement?

Agile project management is present in almost all IT companies nowadays. In 2001, the groundbreaking Agile Manifesto (agilemanifesto.org) was produced. The mindset has changed greatly over the last 20 years. Was it a change for the better?

According to the Project Management Institute1, more than 70% of companies have incorporated an agile approach, and agile projects are 28% more successful2 than traditional ones. Presumably, you also know agile prevalent principles, which are fostered by the scrum framework. This shift requires a different approach when doing projects. In this article, I would like to focus on the refinement which, in accordance with the scrum, is an ongoing process during the sprint. The process of creating, refining and polishing the product backlog. Based on my work experience as a former business and system analyst, and now as a solution architect, I share my knowledge which simply works and explain a couple of interesting observations. So, what does refinement mean in practice? How scrum recommendations conform to reality? Which side reflects the experience – a purist or a practician? If you wish to know the answers and instill a habit of conducting efficient refinement, sit comfortably and move on to the next paragraph :).

Having explained these prerequisites, we shall move on. I am about to look at the refinement from different angles. Two opposite sides are a technical one > so how we, technical people are playing on this refinement ground and the other one, which indeed is a business point of view.

Let’s start with the sprint-time point of view.

At the very beginning, I as an architect need to make sure that all planned stories are well defined and that the analysis for the sprint has finished. In two weeks sprint, it should take no more than 2-3 days. In the meantime, the business team has time to meet internally and brainstorm what are the requirements for the upcoming sprints – in my case they define user stories and acceptance criteria. Then, I organize a pre-planning meeting, on which the business knows what will be in scope for the next 1-2 sprints ahead, and I work with a product owner on the prioritization and ordering. Usually, this meeting gives me a high-level feeling of what should be delivered.

Once it is done, I can focus on the user stories and break down requirements into smaller pieces. Sometimes it happens at the same meeting, but it’s hard to stay focused for more than 90 minutes. It’s really exhausting intellectual work, so the best idea is to organize a separate meeting on the following day.

When the first bunch of requirements is ready, I organize the first estimation session with the development team (remember – according to the new scrum guide, it’s developers team) which lasts for maximum 60 minutes. The outcome of the refinement is the input for the estimation meeting. This gives me not only the estimation score (story points rules benchmark in my case), but I also solicit first feedback from the developers team – questions which I forget to ask, the business should clarify. In the middle of the sprint, the architect should work on the requirements which were discussed in the pre-planning meeting. Ideally, after 2 days of the first estimation meeting, the second one ought to happen. This is enough time for me to prepare another chunk of business needs.

Now, we are on the 7-8th day of the sprint. Biweekly sprint has 10 working days (1 day for scrum ceremonies included). At the end, I need to make sure that the whole scope is delivered and well-tested. In order to achieve that, I am in constant communication with the development team and react to current objectives and blockers – which are my target when I listen to the daily scrum ceremony. Then, on the last day of the sprint, I help the product owner to choose the scope and accept the plan for the following sprint, so that the planning meeting is a little bit easier. It is explicitly visible which requirements are refined and estimated, and which are not. Sometimes a product owner insists on you to agree on user stories, which are not well prepared – but remember, at last it’s the development team who decides during the planning meeting, whether they agree on the sprint scope. It’s crucial to level that because my opinion is extremely important when business makes a decision.

The above schedule may be a good starting point for the team. I always start with following these rules and then, adjust the plan according to the environment. I never forget to upfront set up meetings which happen regularly, so that me and my team follows the same rhythm. The product owner’s calendar is usually full of appointments so it also helps to plan the week.

Now, when sprint-time-related topics are covered, I would like to take a deep dive and discuss the aforementioned refinement as a technical person, who deals with developers. Then, we will move on and we will wear the glasses of a person, who cope with business people.

To start with the team, I feel at ease if I know that the team is not only full of self-managing specialists, but also consists of a tester. So simple, so true. One quality assurance guy should be able to test the work of maximum 6-7 developers. In my case, given the team of 6 developers and 1 tester, when the QA engineer was removed from the team, the overall sprint efficiency decreased by 20%, because others needed to take over his responsibilities. Developers and a product owner acted as testers, usually not having enough time to do that and the quality of the application instantly dropped. I just want to point out, that when being in a cost-cutting team and when the client starts to think that reducing the team may be a good decision, I put a lot of effort to convince them not to do that, since it definitely won’t pay off. Feeling the constant pressure also influences the team’s behaviour during day-to-day cooperation and refinement as well. Developers should do their job, testers theirs and I mine. Switching a business analyst into a scrum master role because the team needs a scrum master is not an option as well. Unfortunately, I saw that had happened and morale plummeted promptly – soon after the team didn’t feel so involved and became workers instead of being engaged consultants.

How about having a small backup during refinements? Great idea! Do you know “tres amigos”? The well-known practice “tres amigos” is a complementary approach to the analysis. It looks at requirements from three different perspectives – business, test and delivery. It boosts shared understanding of the future increment, that will be delivered. Simply, we can build the product of better quality. But it doesn’t have to limit to only three people. I also invite one frontend developer if I know that in the scope of a discussion there is at least one story related to the user interface. I also put on my invitation list one backend developer if I know that we will talk about the business logic. Why? Because:

It is albo possible to invite any other person, who can speed up the refinement process – the scrum is designed to improve so anything can be discussed on a retrospective and implemented in the next sprint, to see if another approach produces better results. Yet I always remember to include each necessary perspective with as small group as possible. My duty is to keep the analysis and architecture up to date. It’s hard to update the analysis “on the fly”. I note all points which will have to be done. Of course, I’m not alone. I address all “to do” points to the team and agree about responsibilities – which is similar to the point of clear roles assignment. For example: they (business) update acceptance criteria and description of requirements in JIRA, and I update analysis, diagrams, user interfaces and all other stuff that we keep in confluence.

Tasks in JIRA should be linked to the confluence pages for easier navigation – easy access to technical, business analysis or user interfaces wireframes is extremely helpful. I keep an intuitive page tree on the confluence to navigate through contents effectively. Speaking of JIRA, statuses such as “IN REFINEMENT”, “REFINED”, “IN BACKLOG” might make the project more manageable and easier to control. For team members, because they can more transparently express their current status and manage their daily tasks and for the stakeholders – because charts and statistics are more accurate.

I follow the principle that drawings express more than words. It doesn’t need to be in plain UML, but it needs to be easily understood by everyone. I draw sequence diagrams to show the sequence of the flow and components’ responsibilities. For the developers, it’s the most interesting artifact when speaking of new integration points. The communication order and input/output data from each of the components help me keep the quality of the analysis at a high level. What is more, I draw state machine/activity diagrams to better express the requirements. Furthermore, I update architectural component diagrams after each sprint – I am not the only person who is using it. The main point is not to be afraid of drawing – it is both the requirement analysis and the documentation of a system for the future. The business will soon start to understand all diagrams and the efficiency will raise – and worth mentioning is the practice itself (I really like this part of my job :)).

When I mentioned architecture, I would like to ask you one question – do you know why we are designing the well-thought architecture of systems that reflects business requirements? We don’t do that because architects want to follow the most up-to-date design patterns. Systems’ architecture which works efficiently is also not the most significant factor. Architects ought to design the best (for the given case) possible system architecture in order to decrease maintenance costs and make the system easy to change. All working components should be flexible enough so as to adapt to the demanding pace of the world. The faster we adjust, the more competitive edge we gain. On the other hand, the more code the system has, the harder it is to change its behaviour. That is why the development principles should be established at the very beginning of the project, since initially it is impossible to notice a bad design. It is worth mentioning that every shortcut and workaround makes troubles one day. It is common that the customer pushes to deliver more and faster. In such situations, I explain all consequences that this decision implies on the project and make sure that the business understands them. It is not easy and sometimes they change their mind from sprint to sprint. That is why the system architecture should be as flexible as it is possible, because changes are intrinsic features of the development process. Nevertheless, don’t make every piece of the system configurable – it should be a subject of discussion and knowing the big picture helps to make the right decision. If the team doesn’t know what is the plan for the next months, I ask for a roadmap or help in its preparation. It is a great support to make better architectural decisions which will comply with other system components in the future. Moreover, the development team understands the context and that for sure increases their engagement.

Not only context is important, but also trust. When I give the freedom and team members can actually make architectural decisions, their motivation increases. I also bluntly express my arguments but I leave the last word to the team – it usually works and decisions are the same as if I were a decision-maker. Trust makes the team dedicated. I never forget that the team consists of experts. It is not possible to know every piece of the system by heart by one person. Their arguments are also generally correct. Sharing knowledge should be a daily practice. A good team leader grows the team and makes it self-sufficient. It’s extremely rewarding when everything is working like a Swiss watch. It also makes my and teams’ work more pleasant :).

After the reflection on the collaboration with developers, I would like to smoothly move to the business environment.

A product owner is a person who sets goals and accepts increments presented on the review. In bigger projects business team, except for the product owner, consists of business analysts, operations managers and others. They all need to find the same rhythm to be able to cooperate efficiently – and I too. The best idea is to meet all of them in person. I am prepared for regular business trips. If unfortunately this is not possible (sic! covid), ask to turn on cameras. Creating a business relationship helps during negotiations. My point of view is absolutely influencial for the business and they rely on my professionalism and experience. Decisions are more accurate if I genuinely care and understand others. Remember this very important sentence: first try to understand, then to be understood. My responsibility is to make the business aware of the consequences. I never let emotions get better of me – instead, I act as a professional. Additionally, I explain business impact on the application level of every decision – only then they would know how to make selections appropriately. I am fully transparent about any concerns and identified blockers. The honesty will be soon appreciated – others would know that they can count on me. Who knows, maybe thanks to that, I will evade incoming fuck-ups?

Equally important is to foster empathy and put myself into user’s shoes. This helps me to deliver the best frontend that it is possible. Commonly, stakeholders judge the application based on the interfaces. If I have enough time, I prepare more than just one user interface wireframe. Obviously, the business needs to select only one, but I act as a proactive and caring team player. It’s easier to talk about the functionalities when everybody sees a draft. Perhaps, we would come up with a better, than initially planned idea. Visualization without a doubt plays an important role, especially during remote work.

Another symptom of effective work is when user stories are well prepared before the refinement. Business needs to conduct an internal meeting about requirements before meeting them in person. I don’t say that brainstorming is not appropriate – it is indeed! But let’s do that at a separate meeting. I, as a host of the meeting, follow the rules which make the refinement easier to conduct. I also guide others if the meeting is heading in the wrong direction. That is why it is good to use scrum master’s knowledge and techniques to foster good practices. When I create meetings, I remind myself of a GOAL principle and write in the description: the Goal of the meeting – so what I want to achieve, the Objective – how I want to achieve that and the Agenda – useful for meetings’ participants to familiarize with the details and the planned length of the meeting. I use spikes if research is necessary and I also use time boxes when I feel that discussion is too long. User stories should be prepared, which means that acceptance criteria should be written down and a description should be present. This approach gives me another opportunity – to send topics and questions related to requirements before the meeting. These pre-sent questions show where are gaps in the analysis and stimulate the discussion. If a meeting is over and questions are still open, I always send them and push for the responses.

I’m sure that even one unanswered question or gap in the analysis will bounce back during development and I will need to answer it at last. I try to instill a habit in my product owner to review acceptance criteria regularly – usually, a product backlog is created at the very beginning of the project. Of course, backlog items may change as well and my job is to make sure that all of them reflect current business needs. Speaking of changes – how we should act if requirements change during a sprint? That is the worst thing that may happen as it complicates developers work. It affects the morale of the whole team – nobody wants to do the same thing twice. If this happens because something was not analyzed enough, I do the lessons learned and at the next meetings, I take a deeper dive into the stories. Splitting stories to the more granular pieces may come as a help. However, if this happens because the business suddenly changes its decisions – I level how much work it requires to deliver something according to new agreements. Small adjustments may be done and I show a sign of teamwork. The business then feels that I do everything to satisfy their needs. On the contrary, they can’t feel that they can ask for a change whenever they want. If something has already been done or I need to sacrifice other stories to implement the change – I ask to create another user story and plan it in the next sprint.

It’s easier to avoid such things when stories are fine-grained. Smaller stories are also easier to test. For example, I show the first version of the interface to the business so that they can verify if what they saw on the wireframe is what has been built. Algorithms can be tested even during development – just ask the business to provide test data and expected output – the team can easily run an algorithm based on the given input. It saves time and I don’t need to test all scenarios manually. In the case of a tight schedule – I propose a scope change. It is good to know the ideal solution which is in business’ minds, but in this situation, I verify which requirements are the most valuable and which may be split and delivered later. I write down all agreements e.g. notes during meetings, bug reporting procedures, etc. – it also saves time. What is more, analysis is part of future documentation. Well written doesn’t require any updates after the sprint. I write it as if it’s the final form so that I don’t need to fix it later.

I think it’s time to summarize and reach the conclusion.

Basically, the better user stories are prepared, the lesser time I spend on the refinement, which follows more precise estimations and implies easier planning meetings. Less time is spent on clarifications and the work goes seamlessly.

It’s obvious that I need to prepare at least one sprint ahead – I am the host of the planning meeting. The product owner is only to select the final scope – I with the team are planning the work in detail. I try to have refined 2 sprints ahead. Why? It builds team predictability. It is extremely important because it is needed to plan features for the whole year – so this increases my quality in stakeholder’s eyes. It also influences the team’s stability – the overall health of the team.

During the planning meeting, I also insist on leaving a 15% buffer of sprint capacity for refinement purposes. It is said that it should take – more or less 10% of the sprint’s time, but complicated projects need more. By saying complicated I mean when we create a new product, a new process or requirements are not well-known and broken down. We need to have enough time to discuss the lowest level design and clarify all ambiguities. This time also helps the team to increase the proficiency of the team’s skills – they learn from each other :).

Having a road map or impact map is clearly very helpful. I balance how much do we use business time on each of the requirements. There is no need to focus on things which are planned a few weeks ahead. The way how I communicate things to the business and stakeholders is also essential – business is not always right. I ought to have enough courage and skills to convey that in a friendly manner.

Is there one truth, one correct answer how to do a refinement? I think not. There is no verdict – no objective solution for that question. It should be empirical, based on the experience with the team and stakeholder’s landscape. Try to implement your ideas – scrum is designed to test and adjust!