Categories
Program Management Tools

5 ways to leverage Bard or ChatGPT as a TPM

Photo by Caleb Jones on Unsplash

Large Language Models (LLMs) took the internet by storm and could support the day-to-day activities of technical program managers (TPMs). Since ChatGPT’s release in Nov 2022, that’s all you hear about across different fields (technology, medicine, legal, and others). In March 2023, Google released an initial version of Bard to intensify this competition in an addressable market of up to $1 trillion. Updates for both tools are happening quite frequently, and the competition is just starting. Other players are joining that wagon, but regardless of your preference, see below how you could leverage them to optimize your work as a TPM. Items in italics represent example prompts.

Prepare presentations

Effective communication is critical for TPMs, and these chatbots can be handy when creating slides from scratch or tweaking existing content for a new target audience. See below a few examples:

  • Find relevant quotes to introduce a concept and make presentations more engaging
    • Give me a quote to highlight the importance of active listening
  • Summarize content for an executive summary slide
    • Summarize the following pilot results in 3 bullets for a presentation to VPs
  • Do some market research to present external data to back up your claims
    • What’s the addressable market for sovereignty cloud solutions in the US?

While Bard or ChatGPT provide text outputs for you to create your slides, you could also go beyond and use tools like Tome and beautiful.ai to have those slides created for you. Besides, Google announced in May 2023 that Google Workspace is integrating Generative AI capabilities into Slides to generate images.

Create code to automate recurring tasks

As a TPM, you probably want and enjoy automating away those boring tasks that you and your team repeatedly do to free up time for more exciting work. While you could automate them without chatbots, they can bootstrap the initial code and save you quite some time. The generated code may not exactly do what you want, but it will be a starting point. See a couple of ideas below:

  • Aggregate and summarize statuses from many tasks
    • Create a Python script using the JIRA module from https://pypi.org/project/jira/ that iterates through a list of tasks in a JIRA saver filter and, based on those tasks’ statuses and their last comments, provides a summarized status (up to 100 words) of the overall status
  • Pull content from several data sources to generate charts
    • Create some AppScripts code that retrieves data from 3 different spreadsheets and summarizes them in a pie chart of the number of production incidents vs. severity in a given quarter

Create content for design and plan documents

While creating intro, background, or conclusion sections for design or plan docs, chatbots can take an initial crack at it so that you do not have to start them from scratch. That could save you time to invest in what is unique in your proposal. See a few examples below:

  • Intro based on other previous, related docs
    • Create an introduction (up to 150 words) that includes the motivations and current state of the XYZ program based on these two docs: [doc #1 content] and [doc #2 content]
  • Create a summary
    • Create a TL;DR (up to 250 characters) of the following document: [doc content]
  • Include external data points with no manual work to curate them
    • List the last ten minor releases of the Linux kernel with their specific release dates and number of commits

Note: For the first two examples, ideally, providing a link to the docs should work, but that functionality was unavailable in either tool (Bard and ChatGPT) when this article was written.

Learn new technical topics

TPMs are regularly challenged to learn new technologies to keep up and contribute to their programs. Chatbots can provide short summaries to get you familiar with unknown concepts during meetings, discussions, or events. They can also be used for deep dives into topics while providing additional references like books or articles. Here you can find a few examples:

  • Knowing new acronyms or terms
    • What’s PSP in the context of network security?
  • Conversational learning in multiple steps
    • What are approximation functions used for in the context of large language models?
    • Can you give a few examples of approximation functions?
    • Can you give a Python code that implements a Softmax Function?
    • Could you modify it to receive an incomplete sentence and try to approximate the most likely next word in that sentence?

Design with Bard / ChatGPT in mind

When designing solutions with your team, check if these chatbots (or other available AI tools for what matters) could help automate or improve some of your products’ features. For instance, your design could include an API call to Bard or ChatGPT to provide a more human-like message given certain parameters (a more personalized email based on a user’s profile, a curated comparison between two products that a user may be searching for, …). ChatGPT plugins, for instance, could augment the capabilities of your solutions.

Note: Since these tools are either experimental stage or the enterprise solutions are still in the early versions, before jumping in and integrating them, you should thoroughly assess the security and privacy policies, and the associated costs first.

Wrapping up

Like it or not, LLMs are here to stay, and it is a matter of finding the best way to leverage them. While some professions may be highly affected or even go away with these tools, the contributions that TPMs can bring to programs are not jeopardized (yet maybe) by what these tools can provide. Find your way to incorporate them into your daily work and be more efficient. Please share any ideas in the comments.

Article’s summary by Bard (no modifications):

  • LLMs can be used to automate tasks, provide insights, and generate creative content.
  • LLMs can help TPMs to be more efficient, effective, and creative.
  • LLMs are still in their early stages of development, so it is important to assess their security and privacy policies and associated costs before using them.
  • LLMs have the potential to revolutionize the way TPMs work.

Article’s summary by ChatGPT (no modifications):

  • Large Language Models (LLMs) like Bard and ChatGPT are being used by technical program managers (TPMs) to optimize their work.
  • LLMs can assist in preparing presentations, automating recurring tasks, creating content for design and plan documents, and learning new technical topics.
  • TPMs can leverage LLMs to improve communication, save time on repetitive tasks, generate code and summaries, and enhance their knowledge base.
  • Integrating LLMs into TPM workflows can lead to increased efficiency and effectiveness, but careful consideration of security, privacy, and costs is important.

Disclaimer: The opinions expressed in this article are solely those of the author and do not represent the views of the current or previous author’s employers.

Categories
Program Management

What I’ve learned from changing jobs

Early November 2021, I started a new job. That moment was bursting with excitement, with people wishing me the best, and with memories of fun times with my colleagues but only I knew the rollercoaster of emotions in the months that preceded the transition. In this article, I share what I learned from it.

Be mentally and physically prepared

The decision to pursue a new endeavor usually happens months before the actual move. My case was not different, and add to it a couple of months for immigration processes. Even though I expected it to be a stressful time, I underestimated it. For instance, I drastically reduced my workout frequency with the excuse that I needed more time to prep for the interviews. Big mistake! I lost several pounds, I was stressed out, and my sleep hours were impacted. In general, my quality of life suffered a hit.

Lesson #1: do not change your habits, prioritize your health, and keep doing whatever you do to relieve your stress. Set the environment around you to go through that period while finishing it mentally and physically undamaged.

Be selective

It may be flattering to be reached out by recruiters from large companies. However, they should not decide for you if it’s time to pursue a new position. If you didn’t think or dream of yourself working for company X before a recruiter pinged you on LinkedIn, you should think twice before jumping into a selection process. It will demand you a lot of time and energy. In addition to the company, you also need to be as selective for the position. Working for a company that looks fancy on your LinkedIn profile but doing something that you don’t like will make you feel miserable.

Lesson #2: The position AND company need to get you excited from the get-go. If only one of them hits the bar, don’t waste your energy. Select the top 2-3 options and discard the other ones.

Get ready and line up your options

Preparation is crucial for any position level. Dedicating time to learn about the company, get familiar with the selection process, and brush up on some skills will pay off in the end. In the worst-case scenario, you’ll learn something useful.

If you’re considering multiple companies (and you should have a few), the order that you interview with them matters. Your top choice should not be the first one. You’ll inevitably make some mistakes or learn something new that could make the difference later between landing a job or not.

Lesson #3: Invest the time to prepare. That boosts your confidence, and interviewers notice when someone has done their due diligence. You’ll get better as you interview. So, avoid interviewing firstly with your top choice.

Limit your criteria

Congratulations! You passed the interviews leading to having a few offers on the table. You only need to pick one. Easy, right? Maybe.

If you have an offer that stands out in many aspects, that’s a no-brainer. If there isn’t a clear winner, you have to evaluate all the pros and cons before making a call. Location, company, position, growth potential, base salary, performance bonus, sign-on bonus, stocks, 401k matching, vacations, health benefits, perks, and many others. This list can go on and on, and you may get into a situation where too much info leads you to paralysis. Only a handful number of criteria should matter to you and your family, and identifying them is critical. I realized that when debating with myself if I should consider X since Y was offering a better 401k matching policy. 401k matching would not even make up my top 5 criteria to choose an offer.

Lesson #4: Pick no more than three criteria to support your decision. Do not look back once you have decided.

Be responsible

One’s reputation is built over several years, but it only takes one wrong move to ruin it. The fact that you are interviewing with other companies or that you have given your 2-week notice does not free you up from your responsibilities. Regardless of your reason to leave, you should continue performing consistently until your last day. That not only leaves a good impression, but in my case, it is in alignment with my core values, and it was the ethical thing to do.

Lesson #5: People will remember you for what you’ve done, but your last actions are more likely to stick to their minds. Maintain your job performance until you are officially out.

Be patient, humble

Here you are on the first day new at your new job! Excitement is through the roof, and you survived the selection and transition process. You were used to an environment where everybody knew you and where you had a solid reputation, but assuming that you’re not a superstar widely known in the community, you’ll have to build your reputation from scratch. Maybe only the hiring manager knows a tiny bit about you. The rest of your colleagues know nothing.

In the beginning, navigating that anxiety of causing a great initial impression and hitting the ground running can be tricky. Humbleness and patience are essential qualities during those times.

Lesson #6: What brought you here may not take you there. Be humble to understand the context and practice active listening when meeting with people. That should set the environment for a durable, successful new journey in the long run.

Summary

  1. During the hiring process, do not change your habits and prioritize your mental and physical health;
  2. Both the position and company need to be a good fit for you. Consider no more than three options;
  3. Preparation is key. Optimize the interview sequence to get better for your top choice;
  4. Pick no more than three criteria to choose the offer to accept and don’t look back once you’ve decided;
  5. Don’t burn bridges and be responsible until your last day of work;
  6. What brought you here may not take you there. Be humble and patient in your new job.

Disclaimer: The opinions stated here are my own, not those of my current or former employers.

Categories
Program Management Software Development

Do not overthink your project dates

“For yesterday”, “ASAP”, “we need it now”, “by EOD today”, “urgent matter”, “we can’t miss it at any cost”, “it’s committed so we can’t change it”, … 😒

Being under pressure to release something soon(er) or on the planned release date is how many teams operate. One may think that pressure is a temporary state. Another may see that as the rule instead of the exception and inherent in the company culture.

An aspect sometimes taken for granted is what success means for a given project. A more purist project manager may claim that if a project is released on time, with the planned scope and within the budget then it was a success. While valid and common, that approach is focused primarily on short-term results.

Shenhar et al. (1997) proposed a multi-dimensional model to define project success that aims to encompass both short and long-term benefits from projects, which includes 4 dimensions: project efficiency, impact on the customer, business and direct success, and preparing for the future. The first dimension is what most organizations primarily focus on and schedule is a major, if not the most important, component of it.

Even though there are truly time-sensitive projects (like an update to comply with new regulations not to incur in fines), there are also projects that are forcefully said to be required by a certain date for reasons that may be questionable. Whenever an unnecessary constraint is imposed, it may lead to wrong trade-offs that come at the cost of impacting long-term goals which could be more significant than the constraint.

The following picture shows that the relative importance of project efficiency gradually declines over time after project completion, i.e., the fact that a project was released on time may have little influence on what happens with it in the field. Still, we spend most of our energy to make that date happen and sometimes forget about the other dimensions. Although success in that dimension may represent a well-managed project, that alone may not guarantee actual benefits for the organization in the long term.

Relative Importance of Success Dimensions is Time-Dependent – Adapted from Shenhar et al. (1997)

As project managers, we should be challenging project requirements and asking why certain constraints are put in place to validate the actual boundaries of a project. That knowledge enables us to drive for efficient execution while keeping an eye on long-term goals to enlighten the customers, grow the business and sow the seeds for future opportunities.

Time-to-market is important but you should not live to make a date at any cost or for the sake of following a plan. Challenge your team to 1) think more about what comes after a release and to 2) value more the product quality and its usefulness to the end customer.

Keep in mind that releasing a product is just the start, not the end.

References:

Shenhar, A. J., Levy, O., & Dvir, D., 1997. Mapping the dimensions of project success. Proj. Manage. J. , 28 (2), 5-13

Categories
Program Management

5 traps that technical managers can fall into

Nothing in life is always a bed of roses and even seasoned technical managers make basic mistakes that impact their teams’ performance. In my previous articles (If you’re a manager, invest more time in your tech skills and For Managers: How to develop your tech skills) I covered the importance of that set of skills and how managers can develop them to help on their day-to-day work. Let’s now talk about the common pitfalls that I’ve seen experienced managers face mostly because they have (or believe they have) a solid technical background. I have to be honest and confess that I’ve caught myself making these mistakes on several occasions.

#1: Fire-fighter mode is ON

Quite often team members reach out to managers to discuss a problem, but they are not actually looking for a solution. All they want is to vent, bring awareness or have a fresh pair of eyes looking into it.

However, it’s tempting for managers – whose common traits include assertiveness and decisiveness – to think they are expected to provide solutions. If the problem is related to an area where the manager has worked in the past, it’s almost certain that a ‘suggestion’ will come up, either due to an unconscious need to show that he/she is still sharp or due to a genuine willingness to help.

The problem with this fire-fighter approach of jumping in and trying to fix the problem is that it can easily kill team ownership and empowerment if not applied in small doses. Coaching techniques [1] could be helpful to suppress that impulse to always address the problem.

#2: Directions instead of suggestions

As a manager, you need to recognize that no matter how flat, small or open your organization/team is, you’ll have power over your subordinates and they will not see you as a peer. That doesn’t mean you can’t have a fruitful and open relationship with your team members.

Once you provide technical suggestions – even in areas where you are the most experienced in the room – the team will receive them differently if they were hearing them from a peer. Some teams may be more vocal and push back if they disagree with the proposals. Other ones may feel compelled to accept them since they came from their manager.

In those cases, the best way to avoid problems is to assess and build a safe environment where people can share their thoughts. Do a quick test: measure the team participation in Sprint Retros with and without their managers in the room. If the team doesn’t feel comfortable to share certain problems because the manager is present, that’s usually a sign that there is some work to be done to make that environment more psychologically safe.

#3: Tech skills to be able to speak up

Managers can leverage their technical skills to better understand what the team is trying to communicate. Active listening [2][3] is one of the major virtues of an outstanding leader and should be practiced during technical sessions too. However, one may think that the main benefit of having those skills is to able to speak up and contribute to solutions.

As a manager, you should try to hold your natural instinct of speaking more than listening and allow the team to brainstorm before you interject them with your thoughts.

#4: Misinterpreting the level of engagement

If a manager is lucky, he/she will spend 4hs/week developing their technical capabilities. During the same period, a developer will spend at least 10x more time (40+ hours). How can a manager keep up with the technical changes in a project? He/she just can’t and, for everybody’s sanity, that’s intentional and expected.

Therefore, a manager needs to be mindful that his/her solution knowledge is at the same time outdated and at a high level. That should dictate how much technical engagement he/she could have and how his/her comments should be positioned to the team.

#5: Tech skills take precedence to interpersonal skills

Nobody will hire a manager because he/she is an outstanding Java developer or an experienced Senior Architect. One is promoted to a management position due to his/her abilities (or potential) to lead other people to get work done through them.

Technical skills can be your competitive advantage, but you should never lose sight that your job requires developing mainly other areas such as leadership, coaching, people development, and project management. Avoid spending too much time developing technical expertise, even if that seems to be more enjoyable.

Categories
Program Management

For Managers: How to develop your tech skills

In a previous post, I’ve covered the importance of investing time to keep your tech skills up-to-date. In this post, I’d like to share a few ways to achieve that. I’ve tried a few of them in the past and they’ve worked for me. A few other ones seem interesting and worthwhile to give them a chance. I’ve taken into account the time constraints for managers when curating the following list.

Hackathons

More and more companies have been using hackathons as tools to drive innovation, build teamwork, and improve internal processes. Even though the target audience is usually the Software development team, managers should leverage those opportunities to get their hands dirty and brush up those coding skills. Since those events usually last only a few days, managers have a better chance to be able to put aside some of their day-to-day tasks to focus on those hackathons.

Lunch & Learn

Knowledge sharing is continuously happening among the team members, but managers quite often are not involved in those discussions. Lunch & Learn sessions are effective methods to share knowledge across different functional areas. If you’re a manager and that’s not a common practice in your company, that’s an opportunity for you to develop your team and, as a side-effect, to get to know what the team has been working on from a technical perspective.

Meetups

Meetup.com provides an amazing and free platform to know what’s going on in your area. Since I moved to the US in 2014, I’ve been a big fan of Meetups, but I have been participating only in project management or Agile groups. Recently I’ve given a chance to DevOps meetups and they turned out to be quite handy. In addition, those Meetups can be a useful channel to share open positions, if you’re hiring people.

Local Conferences

As a manager, you may be challenged to justify why you should attend a development/DevOps/… conference that can easily costs $2-3k when including registration, flights, and hotel. In addition, if you need to travel, the amount of out-of-office time can impact your other management tasks.

As an alternative, if you find a local conference that costs only a few hundred dollars, you have a better chance to convince your organization that a couple of days per year are worthwhile and will not impact much your other duties.

Online courses

E-learning platforms like Coursera or Udemy are the go-to options for many people since they can pace their courses as they prefer. However, online course incompletion rates can be as high as 85+%. I’d recommend not to enroll in more than one course at a time to improve your chance to actually complete them.

Certifications

My opinion about certifications may seem a bit contradictory. Even though I have several certifications, I really don’t care about the actual certifications. The most important outcome of any certification is learning during the process. A certification is just a clear finish line that helps me to get organized and commit to studying. Even better if the certification exam voucher has an expiration date. 🙂

If you take major cloud providers as examples, they provide entry-level certifications (foundational or associate) that cover enough technical fundaments for a manager. Google Cloud Associate certifications are recommended for people with 6+ months of experience, while AWS certifications have foundational (~6 months of experience) and associate (~1 year of experience) paths.

Personal projects

Another approach that requires more discipline but that’s very effective is to define a personal project and implement it. It could be as simple as a to-do mobile app for you and your spouse to share chores. Addressing a personal problem can be the extra motivation you need to get that going.

As a piece of advice based on previous failed attempts to do this, keep that as simple as possible and work on incremental releases. If you can’t complete that within a week, reduce the scope until it fits in that timespan.

Contribute to existing projects

You can easily find an open-source project that’s interesting, but the most interesting ones are also likely to require a massive ramp-up time even for small contributions (bug fixes, test automation, …). If that’s a path you want to take, shoot for tiny GitHub projects (less than 2k lines of code), look at their backlogs of known issues, fork it and try to get a few bugs fixed. Here’s another neat idea to get started.

Another way is to find new projects looking for collaborators. A convenient platform for that purpose is FindCollabs. You could even bring that platform to your company as the official way to engage people interested in working on side projects.

Final tips

With such a breadth of options to develop your tech skills, the most important thing to keep in mind is that you need to be laser-focused on what you want and avoid biting off more than you can chew. Enjoy your journey and, most importantly, have fun while learning.

Categories
Program Management

If you’re a manager, invest more time in your tech skills

It’s quite common to find people who used to have technical positions earlier in their careers and then moved to management positions. There is nothing wrong with that career path but in some cases, those professionals forget to keep up with the technology evolution and end up missing great opportunities in their careers.

Consider, for instance, a Java developer who started her career 10 years ago. After 4 years she was promoted to manager and hasn’t been involved with Java coding for the last 6 years. You can (safely) assume her Java skills are so outdated that she’s not able to do a code review or design a microservice with Sprint Boot anymore. Fair enough, but when will a manager have to do that?

In a fast-paced industry with new frameworks popping up pretty much every month, the amount of content been produced is at the same time astonishing and impossible to keep up. So, if a manager can’t keep up with the speed technologies evolve, why should she even bother to try? Shouldn’t she just rely on her technical colleagues?

Inefficient communication is one of the main causes of project failures

Credibility is key and a solid background can enable that

Communication issues are usually among the top 5 reasons for project failure or challenging execution. Different elements contribute to inefficient communication, but establishing a common language is crucial for both the sender and the receiver to be on the same page about the topic being discussed.

A manager with technical skills can leverage the appropriate terms when talking to her development team to reduce miscommunication issues. Moreover, people usually get more engaged and receptive when they recognize the other ones have a similar level of understanding about the topic. Have you seen developers rolling their eyes when somebody tries to show off his technical skills and end up stumbling over?

Besides, having technical knowledge helps managers when elicitating requirements, troubleshooting issues, handling critical incidents, bridging the communication between developers and executives, and managing project dependencies. Finally, credibility is key and a solid background can enable that.

Projects are getting more and more complex and specialized

Try to think about Software Development projects you were involved about 10-15 years ago. If you were not a kid at that time, you might have remembered some sort of distributed application consuming a data source (most likely a relational database) and providing results to the user in a somewhat simplistic interface. Now let’s get back to today’s reality.

When you look at the current scenario, it’s hard not to think about integrated solutions that demand data analysis/processing, artificial intelligence, consume different services, and provide multiple different UIs. Basic client-server DB applications have become commodities and no company can endure unless they embrace very specialized and deep knowledge from areas like machine learning, augmented/virtual reality, data processing, continuous delivery, and statistical analysis.

As a manager you’d be required to know at least at a high level:

  • What those technologies are used for;
  • How they can be incorporated in the business to generate more revenue;
  • How to get started with them;
  • Which alternative approaches exist and their pros/cons.

To get at that level you could 1) read the basics about the technologies, 2) join and actively listen to design sessions, and 3) have fun coding in your ‘spare’ time.

Influential people know their sources

Power is the ability to influence others and it can be identified in 5 forms:

  • Formal: when you’re empowered to take decisions;
  • Reward: when people realize that you’re responsible for rewarding them by deciding salaries, promotions, bonuses, and so on;
  • Penalty: when people perceive you can penalize them if they don’t follow your directions;
  • Expert: when people perceive you possess important functional knowledge;
  • Referent: when people enjoy working with you or in the project you manage.

Formal and Reward types have to be granted and do not depend solely on the manager. Penalty may be effective, but it usually activates the sympathetic system which brings more stress to the relationship. Referent demands time and development of soft-skills which are quite hard to change. Expert power can be your best ally to enhance your ability to influence and lead your team.

Major tech companies look for Technical Managers

Understanding the market demand and how high-performing companies (like FAANG) structure themselves can give you a few hints about the kind of professionals that companies are looking for. If you follow these companies’ news or know people who work for them, you know that they have different flavors of technical management positions:

/Technical(.*|\s) Manager/g.

  • Technical Program Manager
  • Technical Engineering Manager
  • Technical Project Manager

That model is already being used as a reference by other companies. So, career-wise, deepening your tech expertise can help better positioning yourself for high-demanding positions.

Wrapping up

Putting the hours to learn technologies, even when you won’t immediately apply them, will pay off in the short to medium-term. Your team is more likely to value your opinion and feel like you’re one of them. Tech skills can be your competitive advantage if you enjoy getting your hands dirty, but as Uncle Ben says ‘with great power comes great responsibility’ 😉 . There are a few pitfalls that you need to avoid not to backfire your plan, but that’s a subject for another post.

Categories
Program Management

How to improve your project estimates? – Part 1

Regardless of your position and company, you’re quite often requested to provide estimates for the work you need to do. Providing an accurate estimate is definitely a tough task but there are ways to improve your chances to get closer to the actual time spent to develop the work.

For time estimation, we can categorize the estimation techniques in two groups: absolute and relative. Absolute estimation is the more traditional way where you provide a quantified value according to a specific unit, for instance, 16 hours, 2 days, a week. Relative estimation turned out to be quite common too and focus on comparing the sizes of two or more tasks by abstracting the unit itself. Story points and T-shirt sizes are usual examples of relative estimation approaches. In this post, we’ll be focusing more on absolute estimates. Relative ones will be covered in a future post.

Regardless of the estimation approach you decide to follow, there are a few common mistakes you should try to avoid:

  1. Provide estimate without knowing the scope: Usually, people are pushed to provide estimates without understanding what they are supposed to do. If you’re estimating stories or tasks, make sure you’re able, based on the acceptance criteria and/or description, start developing that piece of work right away. If you cannot do that, ask for more explanation, discuss more with the PO or with the team.
  2. Be the only person weighing in on an estimate: If the estimate process takes into account the opinion exclusively of the assignee, it’s likely that few factors will not be considered in the estimate. Challenging someone’s estimate is simple and effective to make sure that different variables were analyzed when providing the ‘magical’ number.
  3. Be restrict to the coding effort: Developers will probably take into account only the time to write the code and build it. If you ask a QA analyst for an estimate, they will probably consider only the time to start validating and provide test results. None of them are to be blamed. They are just reacting to the environment and the kind of activities they are expected to perform. Unless you have an explicit list of expected checks/activities to be performed, usually referred as Definition of Done (DoD), your team will not have a consistent and common understanding about what’s provided when something is marked as Done.
  4. Be afraid of saying ‘I don’t know’: Saying ‘no’ or ‘I don’t know’ is usually seen as a sign of weakness or lack of experience. If your team is saying that, you’re blessed! Don’t judge them! Realize that’s an indication that they are being honest and that additional work may need to be done before an estimate can be provided. In those scenarios, you could 1) have more discussion to try to clarify the work or 2) create spikes (or Proof of Concept – PoC) stories/tasks to build the knowledge and reduce the risks of unrealistic estimates.

Absolute estimating

Without taking sides (absolute vs. relative), there are ways to improve your chances to come up with a realistic (or at least kind of). See below two techniques used for absolute time estimates:

  1. PERT (stands for Program Evaluation and Review Technique): Instead of providing one single value and stick to it, PERT requires the estimator to provide three values considering three different scenarios: pessimistic, most likely and optimistic. Those three values are included in a weighted average assuming weight = 4 for the most likely estimate. Optimistic estimates can, for instance, consider that some dependencies will be provided right away, while pessimistic ones can assume some risks will become true and will inflate the work to be done. The PERT formula is as follows: P = (O + 4*M + P) / 6.  Adding one or two standard deviations can give you an extra cushion for unknowns. More details about how to calculate the standard deviation you can find here. By using PERT, you’re explicitly thinking about other scenarios and that exercise will help you to improve your estimates.
  2. Analogous estimation: This technique relies on estimates of past similar tasks to size a piece of work. Historical information is used and the differences between the past and current work are discussed with the team to come up with the estimate. Even though this can a useful technique, there are two aspects to keep in mind:
    1. Software development tasks are hard to be similar: While engineering activities (like building or painting a wall) can be quite similar from project to project, software tasks can look similar but may end up being quite different depending on the environment and the assignee.
    2. The time required to find a similar task: Depending on the amount of historical information, finding a similar task can lead to a waste of time. If using analogous estimation will slow down considerably your process, it’s an indication that it may not be a good fit. Remember that unconsciously everybody will end up using their previous experiences to estimate the work.

An elementary mistake is to consider effort = duration. If you estimate the effort in days and use that as the task duration, you’re unrealistically assuming 100% of allocation with no room for attending meetings, resting, reading e-mails and so on. A decent strategy (even though it requires more management work) is to consider a percentage (you could start with 75%, for instance) and tweak it for each team member depending on the average actual hours worked. That percentage will be tightly coupled with the environment and the internal processes of the company. The leaner and the more agile your company is, the higher that percentage will be.

In the next post, we’ll cover relative estimating and the different techniques to improve it.

 

Categories
Tools

Add labels when creating issue on JIRA

JIRA is definitely a flexible bug tracking tool and one of the most powerful features is workflow customization. This post describes how to add a label automatically when an issue is created. This can be useful when you want to flag an issue and later capture that in a filter or board. A practical example is to flag Bugs that are created so that they can be reviewed during Bug Scrub meetings. In order to add a label we need to add a custom script in a post-function.

  1. As admin, go to Administration >> Issues >> Workflows >> Click on Edit in the workflow you want to change
  2. Click on the ‘To Do’ step (assuming your workflow is the default one)
  3. Click on the ‘Create’ action >> Post Functions tab >> Add post function
  4. Select Script Post-Function >> Custom script post-function
  5. Paste the following code snippet replacing ‘BugScrub’ by the tag you want
  6. Publish the workflow => Important: If you don’t publish the draft workflow, no changes will be reflected.
import com.atlassian.jira.ComponentManager
import com.atlassian.jira.issue.label.LabelManager
import com.atlassian.jira.component.ComponentAccessor

def user = ComponentAccessor.jiraAuthenticationContext.getLoggedInUser()

LabelManager mgr = ComponentAccessor.getComponent(LabelManager.class)
mgr.addLabel(user, issue.id, 'BugScrub', false)

 

For additional information about the addLabel method, please refer to the official documentation.

Categories
Tools

WAS operator in JIRA

JIRA is one of the most used bug tracking system and one of its main features is the search mechanism. There are two modes when searching for issues on JIRA: Basic and Advanced. The basic one is composed of a set of filters you can select and define values. Even though the basic mode is enough for most cases, it does not allow you to run some more complex queries.

Today I’ll present the WAS operator that can be used by writing JQL queries in Advanced mode and that allows you to search for issues based on the property values in the past. This can be extremely useful if you want, for instance, to collect history data or to evaluate changes against to such a property.

This operator can only be used with the following properties: Assignee, Fix Version, Priority, Reporter, Resolution and Status fields only.

Examples:

Find all bugs that were open last week

issuetype in (Bug, Defect) AND resolution WAS IN (Unresolved, EMPTY) before endOfWeek(-7d)

Find all stories that were resolved last week and that are now closed

issuetype = Story AND status WAS Resolved DURING (startOfWeek(-7d), endOfWeek(-7d)) AND status = Closed

Find all stories that were unassigned in the last two days 

issuetype = Story AND assignee WAS EMPTY DURING (endOfDay(-2d), now()) AND assignee IS NOT EMPTY

Categories
Program Management

Should I plan future Sprints?

I’d like to cover one topic that may be a little controversial among managers or agile practitioners: whether planning sprints in advance is acceptable or not in a Scrum project. Should I plan only the Sprint my team will start or should I plan future Sprints?

Being agile is about identifying and reacting to problems as soon as possible. The three pillars of a Scrum project emphasize how to do that by inspecting, adapting and being transparent during the Scrum events. However, there is no Scrum event to go beyond the planning of the current Sprint. This is why the most purist people don’t plan future Sprints.

Even though Scrum guide does not mention this, positive results may be realized when planning more Sprints in advance. These are some benefits of doing that:

  1. Anticipate problems that require immediate actions
  2. Increase likelihood of meeting external milestones (i.e. those that do not depend on or cannot be controlled by Scrum team)
  3. Identify need of hiring new people for the team

However, how can this be done without impacts (or with minimum impacts) in the current sprint, since team members should be focused on developing the scope of the Sprint?

Slightly change Backlog grooming sessions can be a good alternative. During grooming sessions the Scrum team and the Product Owner discuss about the Product Backlog with a clear goal: finish the meeting with an improved Backlog. The definition of “improved backlog” can vary from team to team, but usually attendees focus on detailing more the user stories and their acceptance criteria. However, these sessions can also be used to create sub-tasks, to estimate and to assign them.

With a Backlog with sub-tasks and their estimates, the Scrum Master can distribute Product Backlog items in the future sprints, based on the Product Owner prioritization. Having done that, it is possible to check if some milestones look feasible, if people are over-allocated, which may require hiring new people to meet some dates and features, and so on. In addition to this, having 1:1 meetings between the Scrum Master and each team member, once a Sprint for 30-60 minutes, to review estimations and assignments improve the accuracy of the Backlog. This would require an additional effort for the Scrum Master of about 8 hours / sprint, considering a 8-member team, as well as a total of 8 hours when summing up 1 hour of each member. This can be an important practice to mitigate risks.

Important: What is planned for future sprints is not a commitment. A Scrum team can only commit to a Sprint goal after the Sprint Planning.