Written by Recently Saket had a conversation with a colleague who had interviewed for an Agile Project Manager cum Scrum Master role. He shared the set of questions that were asked to him during the interview. In this blog, Saket tries to give his views on those questions from the perspective of Agile Project Management.
What is Agile Estimation Methodology?
In agile, the goal of estimation is primarily prioritization rather than estimating the end date or the delivery date. Calculating the end date is a kind of anti-pattern in Agile, at least during the initial stages. Story point estimation is a judgment related to the size of the work that talks about how much time or effort it will take, what amount of complexity it has, and the expected challenges to complete it. It is majorly based upon the volume and not the value. There is almost no correlation between the value of the work and its estimation. The value of the work can correlate with the prioritization of the work but not with its estimation.
What are the ways of estimating in Agile?
The Agile Manifesto says that the people who will perform the task should only estimate it. Therefore, the estimation should be done by the development team itself. There are various tools available like Planning Poker, which can help gather a shared and unbiased understanding from different team members. The idea is to create a common understanding and ensure that all the working members share a common perspective about the complexity of the work.
How to commit a timeline to the client about project delivery when you have a product backlog?
Agile does not support providing a timeline much ahead of the actual delivery. Primarily, in the agile world, we work on a need basis and promote continuous delivery. The idea is to be continuously engaged with the stakeholder and prioritizing the backlog, divide backlogs into stories and then give the timelines of stories in terms of sprints.
Sometimes, the customer demands a prior estimation or a ballpark figure of the estimates. In that case, we can provide a forecast of the date, kind of a range depending upon a high-level overview. There is always a risk associated with this kind of estimate. We should always be proactive in declaring the risk with such an estimate.
How to estimate iteration and commit project delivery when you have fewer internal resources?
Ideally, when such a question is asked, you should start by stating that this is not a recommended approach, not in the Agile way of doing things. There used to be a time when the pre-sales team would commit some timelines without any idea of how the work will be delivered. Those days are now over. You must ask the customers for a certain time frame before making any commitment. Your role as an Agile Project Manager is to align with the internal resource team during this timeframe. First, you need to get an idea of the quantity and quality of resources available to you. Once you have an idea of the resource’s availability, you are in a better position to do resource planning and share the timelines for the sprint.
However, sometimes it might happen that someone has already committed before you. In that case, my suggestion is to update the stakeholder and customers about all the associated risks and assumptions upfront. Remember, transparency is an essential factor while dealing with customers.
How to answer when a client has asked to deliver early than the committed timelines?
Such a situation arises very often. For example, we have seen that most of the time, the customers ask for early delivery or change the requirements. In such conditions, you as a Project Manager need to understand the situation and empathize with the customer before thinking about handling it.
There may be several reasons for such a demand from the customer, and the solution may also vary from situation to situation:
- If there is a business crisis, your team needs to work along with the customer to determine the best way to deal with the situation. There may be chances that the team has to invest extra time and effort to deal with the situation together with the customer.
- Because of priority change or a management change: This is fine if it happens before the sprint has started. However, if this happens mid the sprint, you need to understand the reason for this change and communicate the risk of adopting it. Along with the risk, you should also communicate the costs involved.
- If it is a small change that can be accommodated with the current sprint, then perhaps it is in the best interest of all to create a separate story for it and get it delivered as long as it doesn’t impact the existing plans.
How to monitor the progress in Agile?
Theoretically, Agile speaks of self-motivated and self-monitored teams. As an agile project manager or a Scrum master, your role is more of facilitating rather than monitoring the team’s progress. It is more about exposing the issue. To make things transparent to all the team members so that they are aware when things are not working, and they can do something about it.
Practically speaking, some quantitative tools can help in getting a picture of the progress being made by the team. For example, tools like the Burndown chart, Velocity chart, sprint boards, and dashboards can give you an idea of the present state of sprint commitment.
Also, there are multiple dimensions of monitoring:
- Output dimension: How much story point your team is delivering. What is their average team velocity? Is the velocity maintained across different sprints or not?
- Quality dimension: What is the quality of the code they are delivering, the number of bugs, the number of code review defects per sprint, etc.
- Relationship or Behavioural dimension: How is the collaboration among different team members. Are they working at a sustainable pace? Are the team members happy and satisfied with the overall project environment etc.?
- Customer orientation: How well they are meeting customer expectations. How are the team bonding and team communication with customers etc.?
So, as a manager, you must look after all these aspects of monitoring in the team.
How to monitor the quality in Agile?
As mentioned above, quality is one of the many dimensions of monitoring. The team members in themselves are responsible for maintaining and enhancing the quality of the product.
Again, the quality can be judged in multiple dimensions:
- Code Coverage: This indicates what percentage of the total code is being covered by the test cases.
- Code patterns: This indicates the way code is written. What is the re-usability factor? What is the number of Lines of Codes (LOCs) per file etc.?
- Defects Density: This indicates how many defects are reported per test cycle.
- Defect Fixing rates: This shows that how fast your team is deploying the fixes of the reported bugs.
- Rework: This is another way of assessing the quality of your project. If the amount of rework is minimal, it usually signifies a healthy project quality.
- Code Review Bugs: This metric shows how many bugs are being captured in the review process and are prevented from advancing.
What kinds of risks do you foresee during a sprint?
There are many possible categories or areas of risk, and it may vary from team to team or project we are working on
Requirement risk: Usually arises due to an understanding gap between the original requirement and the conveyed requirement to the team. This might lead to improper efforts estimation and can be a big risk.
Technical risk: Sometimes, we assume few things to work a certain way, and then they simply do not.
Human resource risk: People can fail to show up sometimes, they get sick, something urgent comes up, etc.
Stakeholder risk: The customer was supposed to provide some inputs, some data that was crucial for the sprint delivery but failed to do so.
Infrastructure risks: Things like these happen too. There is an internet outage, electricity outage, servers not responding properly, etc.
Project management/commitment-oriented risk: This happens when the customer comes back with a new set of requirements in the mid of a sprint, leading to scope creep.
What precautions do you take for mitigating the risks?
Few risks are infrastructure outages, or human resource risks can be mitigated up to a level by advanced planning and creating a backup plan. You need to have a Business Contingency Plan or BCP in place to take over in such scenarios. Uniform distribution of data and responsibilities can further reduce such risk.
Any foreseen risk should be communicated appropriately to various channels in advance to make the contingency plan available at each level.
Finally, each risk encountered or foreseen must be drafted in a risk register along with their proper RCA or Root Cause Analysis. A risk register is an important tool that helps referencing previously faced risks and the measures taken to mitigate them.
How to resolve the conflicts within the team?
It can be a trick question too. First, you must understand that Agile suggests that the team members resolve all their risks by themselves. You should only intervene when the impact of the conflict is severe and imminent. So, you need to understand the nature of the conflict first:
- If the conflict is healthy and not drastically impacting your deliverables, then you should let them resolve it by themselves because you want to make them learn how to resolve their conflicts.
- If the conflict is not that easy and seems to have stretched longer than what can be tolerated, then you may do a lighter intervention rather than taking complete control of it. It would help if you facilitated a conversation so that they can resolve it.
- If the impact is huge and needs to be acted upon immediately, then try to do whatever is in your power to resolve it.
In agile, who all are included in estimation? As a project manager, what will be your role in this estimation?
Agile clearly states that the person who is going to work upon the task should be responsible for estimating it. That way, it is the responsibility of the technical team to review and estimate the stories. However, this does not mean that you do not have any say in this process. You can observe the process of estimation closely and can validate the estimations, too, if needed. You can also challenge some estimations if you feel that they are not correct. This might be difficult at the start, but once you are familiar with the estimation process, you will realize that a pattern emerges out of it, and it becomes easier for you to get a fair amount of ideas to validate the estimation shared by the technical team.
These are a few of the general questions that an agile project manager candidate usually goes through. These will undoubtedly help you in delivering much more value during your interview. If you would like to ask any other question or have ever faced any such question in an interview and wonder what might be the correct way of answering it, please feel free to let us know in the comments below.