A strong Business Analyst (BA) develops business solutions by eliciting and analyzing a client’s processes and requirements. They are often at the “top” of the requirements funnel and are highly proactive, detail-oriented, inquisitive, and resourceful.    

They are the ones that know why a product is needed, what should be developed, and when it should be delivered. and when it should be developed by your team.   

Great BAs can also voice their own ideas and bring additional value through competitive analysis, thus reducing costs in a variety of ways or identifying easier pathways to the project’s end goal.  

What skills does a strong BA usually possess?  

Precise communication.  

One of a BA’s most valuable skills is the ability to shift tone as needed and identify the pain points of stakeholders and the project management team, acting as a liaison when necessary. A BA’s communications flexibility can be a crucial part of smoothing out the wrinkles so that everyone’s clear on what’s being done and bureaucracy doesn’t get in the way of the work.   

Facilitation and solicitation skills.   

Great BAs know how to assuage or persuade depending on the situation. Identifying which battles are worth fighting and which to leave by the wayside will ensure the core focus of the project is accomplished while stepping on as few toes as possible.    

Strong design, data modeling, and documentation capabilities.   

BAs should be able to crunch the numbers, making sure everything’s on track and secure the most efficient path toward the finish line (or if things happen to go awry, devise an alternative solution). Of note here is being able to come to their own conclusion: what the stakeholders or project team thinks is obviously very important to consider, but it shouldn’t color the BA’s independent analysis too strongly.   

Objective thinker with attention to detail and a systematic approach to problem-solving.  

BAs have a lot of people and tasks clamoring for their attention at any given moment. You’ll want a cool-headed thinker that can navigate that multi-tasking and keep an even keel when the stress of the project might cloud other peoples’ judgment.    

Technical toolset for issue identification, isolation, and solution-crafting.   

Having the know-how to hop in on revisions, zero in on problem areas, and offer useful insights to project members is a big part of the job—BAs shouldn’t be shy about getting their hands dirty if they need to. In essence, it’s important that BAs have an arsenal of investigative and analysis tools at the ready and develops the savvy to know which is likely to be most useful and successful. 

Interpret and document business processes through document analysis and stakeholder conversations.   

This is a fancy way of saying top-notch BAs can deftly separate the signal from the noise. They’ll know how to parse jargon and be able to reduce overly complex processes to their essential components. This simplification operates on two fronts: making sure the project team isn’t expending extra effort but also sidestepping attempts to blur the reality of the situation in the case that things start going off the rails. Should issues arise, good BAs can determine who or what is causing hold-ups and resolve the situation amicably.      

How is a Business Analyst different from a Project Manager?  

• A Business Analyst is not a Project Manager (PM).key differences in roles are: A Project Manager is assigned to manage project cost, timeline, and task completion while resolving issues and managing resources of a particular project. 
• A Business Analyst needs to ensure the delivered product meets the stakeholders’ requirements.   

Can a Project Manager also be a BA?  

With the proper skillset, a Senior Project Manager can function as BA for their team or project if it is small in scope. Larger, more complex projects warrant a separation of PM and BA duties and responsibilities.  

Can a BA also be a Project Manager?  

With the proper skillset and experience, it’s definitely possible for a BA to act as PM. If you try this approach, though, we’d recommend having a Senior PM or similar act as a mentor for them on the project if it’s the BA’s first time in a PM role.   

Why You Should Have a BA on Your Next Project.  

While the resource cost of a senior-level BA isn’t insignificant, the value benefits usually far outweigh the investment. Here are the top reasons you might consider bringing a BA on your next project.  

How does a BA create value over the course of a project?  

A BA can add value to a project by reducing project costs by building the right things the first time, for example.  

The biggest waste on a project is often the development of incorrect or unnecessary features. As a direct conduit to the client stakeholders, the BA can continuously help to prioritize the right features and keep the scope laser-focused throughout the duration of the project. This often manifests itself as developing clear acceptance criteria so all are on the same page when a task or feature is complete and meeting requirements successfully. 

A BA can help find more cost-effective solutions.  

For prioritized features, a BA might find more cost-effective solutions by repurposing tools already available, as well as the integrating of current client processes. Often, a slight rework of an existing business resource can be a much more cost-effective solution than brand new development from the ground up.  

A BA can add more accuracy to, or even reduce, cost estimates.

As features are developed, a BA can continue to trace the development back to requirements and provide clear test cases, data, and results verification. By benchmarking system KPIs simultaneously as requirements definition, a BA can evaluate the impacts a new feature could have on an existing system. Having clear benchmarks is also a great way to show tangible project success in areas like system performance or user satisfaction.   

A BA can discover new business benefits and propose value improvements  

By getting to the root of the business need, BAs can provide new ideas on how to improve the user experience while driving new monetization channels, all of which can result in ROI increase.  

A BA can assist with change management.  

Change management is the project management process dedicated to assessing how proposed changes to a project will impact everything else. BAs can chip in to figure out how changes will affect current functionality, project scope, timeline, and budget, then make a judgment call on a case-by-case basis.    

How do I know when I need a BA?   

All projects are unique and not necessarily deserving of a dedicated BA. In general, if you or your team have concerns about project size, scope creep, or the PM’s experience, considering a BA would make sense.   

Evaluate the size of the project.  

The more moving parts, team members, and expectations there are, the more opportunities there are for miscommunication and wasted effort. Consider the size of both the team and the scope of deliverables. The larger the project size, the more complex the interfaces and interactions with other client teams will be—and the more valuable a BA will become.   

Examine the scope and detail level of project deliverables.   

Project goals must be clearly defined at the outset of the project and thoroughly pruned and maintained over the duration lest they become inflated through scope creep. A combination of the original scope being hazy and/or poor requirements management during the project leads to scope creep, which can bloat the cost and schedule of a project over time. One of a BA’s core skills is to optimize requirements management and keep the score narrow, so if that’s a big concern on your mind, talk to a BA and see if they’re right for your project.   

Check the experience level of the Project Manager/Product Owner on the project.   

The less experienced the PM, the greater benefit a BA can bring to the team. For a freshly promoted PM, having a BA support them and offer an experienced viewpoint they can reference in real-time can be reassuring and help build confidence for future projects. That’s not to say that experienced PMs can’t benefit from a BA, of course, but in those cases, the BA will likely operate as an equal or in a more supplementary capacity as opposed to a mentor-esque role they’d have with a newer PM.   

Regardless of your PM’s capability level, if you’re tackling a project of a size or scope that’s new for them, check-in and see how they feel about a BA. Even if the BA isn’t on board for the full duration of a project, having a BA’s help for, say, initial requirements definition or stakeholder meetings could be a very welcome addition.   

Need a BA? We can help.  

In the right scenarios, Business Analysts can be a fantastic asset to keep everything nice and orderly across a project’s lifecycle. The key is knowing when and how to leverage a BA’s skillset to maximum effect. To that end, we’ve covered what a BA is and does, differentiated between PM and BA skillsets, how BAs can offer value across the project lifecycle, and how to determine whether a BA is right for a given project. Now that you understand when and how to leverage a BA, you’ll know how to tackle your next project right from the start—and whether a BA will be in the room with you. Good luck!  

Have a project that you think needs outside eyes? We’re experts in building digital experiences. Come talk with us about turning your idea into a reality or getting your project over the finish line.  

The post It’s Not Personal, It’s Business (Analysts): What Exactly Is a BA and Why Do You Need One? appeared first on Big Nerd Ranch.

You need to build rapport and remain in touch and aware of everything happening. At every stage of client development, there are different approaches and requirements. It’s important to analyze your relationships and ensure they’re successfully moving across the client-partner lifecycle. 

The lifecycle of the client-partner relationship 

Ideally, the lifecycle of a client-partner relationship begins at acquisition and continues on from there. However, not every relationship goes through every stage of development. Some will be market-based, antagonistic, and at arms’ length forever. Some have short or extremely long lifecycles, while others develop quickly (or even skip phases). 

 Once you understand the lifecycle stage of your client-partner relationships, you can begin to manage, analyze, and develop them appropriately.   

Acquire
Brand-new accounts. At this point, we know very little about them. Transactions have a market basis and are centered on product exchange and price negotiations. It is at this stage we need to determine if this account has potential. And if it does, to secure initial projects.  

Onboard
Early accounts. During onboarding, we have investigated the possibility of a relationship and formed social bonds. We must work to identify key contacts, buying personas, the decision-making process, and advocate key account status. 

Engage
Developed accounts. Here, we have an increased level of connection, inter-organizational linkages, social ties, collaborative teams, and a strong emergence of trust. Our focus is on sales, account penetration, new revenue channels, increased business volume, and hidden pain points. 

Grow
Loyal accounts. We have projects moving toward a common goal and increased interdependence. At this stage, our focus is building the partnership, focusing on process-related problems, becoming a first-tier vendor partner, and establishing undemanding offerings. 

Nurture
Partner accounts. We are extremely close to the organization. Together, we are focused on joint value creation, establishing semi-autonomous project teams, and establishing a cultural accord.  

Lights-On
Troubled accounts. We notice work stopping or slowing, lines of sight into future work has become blocked, and the relationship is leveling down. We focus on maintaining existing buyer relationships, keeping updated with industry and client news, and looking for new opportunities.

Analyzing your client-partner relationships 

Competitive advantage is achieved not just by managing individual efforts, but by managing clients. This is best done by solving their problems. The ability to solve client needs at the lowest possible cost with timely delivery is the path to entering that market. This is the end goal of the account leaders. 

When analyzing your client-partner relationships, consider:

• What stage has the account reached? 
• What is the potential for its growth?  
• What strategies can we leverage to support this account?  
• What product-line issues can we pinpoint that are a priority for this client?
• What process-related issues can we pinpoint that are a priority for the client? 

As an account leader, your goal is to appropriately advance the client-partner relationship to anticipate and suit your client’s needs. By building relationships and remaining conscientious of the client-partner relationship, you can better analyze the status of your accounts and develop them toward your mutual goals. 

Managing your client-partner relationships 

To effectively manage relationships with your customers, focus on solving specific problems associated with various levels of rapport. When trust is still being built, concentrate on projects with high impact that have lighter effort.  

At the most basic level, clients come to us to solve problems. Most times, they are trying to resolve issues related to product functionality. These are product-related issues that can be resolved with respect to performance and compliance with specifications. 

On another level, our service is integrated into our clients’ value-added process. The fit of the solution, the method of delivery, and the technology used all influence the buyer’s process. Issues related to integrating our value into the buyer’s value chain are process-related issues. 

At the highest level, customers are striving to achieve their own strategic goals in their markets. These are facilitation-related problems. Facilitation-related issues relate to aligning strategic objectives with clients, creating mutual value, building trust, and integrating systems and people. 

The post How to Effectively Manage Your Client-Partner Relationships appeared first on Big Nerd Ranch.

If run well, project retrospectives result in a wealth of insights into opportunities for growth and can be a powerful tool in building team rapport and expertise. We’ve seen great ideas come from these broader retros like splitting larger teams into feature/requirement squads, how to ensure we’re budgeting for the right roles during the sales pitch, and improving our load testing process.

Needless to say, we’re big fans of project retrospectives and wanted to share what’s worked for us.

Have an objective facilitator

Generally, the team scrum master will host your sprint retrospectives. While they are the most objective person on the scrum team, it’s challenging for them to participate AND facilitate even though they may have great insights to share. Including an outside party means that every person on the team can engage in the discussion without also owning the retro board and taking notes. An objective facilitator will also provide a new outside perspective to refresh the way the team has been thinking and working. Unsure of where to find someone? See if there’s a scrum master from another team who can jump in. Or even a project, program, or account manager. It’s a great upskilling opportunity for them and your team gets the benefit of their observations and wisdom.

Choose an intuitive tool and method

We can’t give away all our secrets, but we will share a few tools that we like to use. My personal favorite is stickies.io. It’s free, super-fast to create an account, and the UX is intuitive. It is a bit limiting on the questions/themes you can use, but we haven’t found that to be a deterrent to valuable meetings. Another useful tool is FunRetrospectives. This one is also free, doesn’t require an account, and has a few options for full, prepackaged retros including fun activities. It’s also quite intuitive and easy to use although the design may feel a bit dated. Lastly, we like Miro. This one is much more freeform so you can structure your retro the way you want. If you’ve got your own personal favorite process that doesn’t line up well with the other two, this is the tool to use! You can set up a free account with limited access to get you started, but if you plan on using it regularly you’ll need to spring for a paid version.

Make it fun!

While retros are often serious, action-oriented discussions, it’s a good idea to let everyone loosen up a little and offer opportunities for laughter and joy. When the team is at ease, they are more likely to share their inputs, collaborate, and build rapport with their colleagues. Since we’re a very geographically dispersed company, we host all of our meetings virtually and have a handful of remote activities that we use. Some of my favorites are themed zoom backgrounds, playing music during quiet times (you can even take requests in advance), using emojis or gifs for voting or other activities, and games like Two Truths and a Lie or Would You Rather. You’ll probably run into some (hopefully) productive tension throughout the retro, but making time for the fun stuff will make it that much easier to collaborate.

Schedule enough time

This will ultimately be driven by the number of attendees but we’d recommend at least 90 minutes to two hours to ensure a dynamic discussion where everyone is heard and action items are thoroughly discussed and documented. We know long meetings aren’t everyone’s favorite, but if you can get all attendees engaged, the time will fly by. There’s nothing worse than cutting people off in the middle of a great conversation because everyone needs to leave. To keep things running smoothly, be sure you have an agenda and stick to it (within reason of course; don’t derail fruitful discussions).

Document and share your results

I know I mentioned that learnings can be shared across the organization but it’s worth reiterating. I can’t count how many times I’ve left meetings with great action items or ideas that are never discussed again. What documentation and sharing look like will depend on your company. Do you have an intranet? Playbooks? Regular cross-functional leadership meetings? Or has communication and tracking of institutional knowledge always been a challenge? You may find that an outcome from the retro is a desire for better documentation and communication. What better way to start than with the retro itself! 

With these five tips for conducting a project retrospective, you can easily gather and implement some high value-added process changes like starting a project with a solid but flexible Jira framework or implementing a comprehensive QA testing process. We encourage you to try hosting your very own project retrospective to witness what value can be delivered to your organization!

The post The Importance of Project (Not Sprint!) Retrospectives appeared first on Big Nerd Ranch.

There are myriad reasons your team or organization may switch from waterfall to agile. Perhaps you’re in the midst of a digital transformation. Or maybe you’re experiencing rapid growth and want to respond more proactively to the market. Or potentially, like many of our clients, you’re working with a vendor to launch a new digital product, and you’ve read that you should use agile to manage the backlog after handoff. We’ve coached many teams through the switch from waterfall to agile, and we’ve learned a few things along the way that may be helpful to you.

Beta Test and Take it Slow

Change is hard, right? We’ve all been a part of challenging technology rollouts or process improvements that have been painful and impacted the day-to-day work. While it would be ideal to shift your entire business over the course of a week, you and I both know that’s impossible. 

Instead choose one cross-functional team, a single department, or a single product to kick off the agile transformation. Slowly beta testing with this small group is less risky, allows for more insight into team sentiments, and means you can try small, incremental changes and quickly measure their effectiveness before the larger rollout. 

As a part of that team, you want to be sure to have a Product Owner, a Scrum Master, and an Engineering Lead to guide the team, set priorities, and drive collaboration. While we’ve seen mature agile teams function well without these roles, it’s important to set a strong foundation for your new practice. 

Explain Agile and Highlight the Pros

When kicking off with any team, I like to share the agile manifesto with them. This sets the foundation for a fruitful and robust discussion. Second, before you change any process, explain the pros of agile. 

Some you may want to share are: 

• It’s flexible
• The product will get to market faster
• It allows for better communication and transparency across the team

It’s also helpful to discuss the notion of “fast failure,” or the idea that they’ll quickly pivot based on user feedback instead of discovering weak points after full implementation.

Learn the Tools and Train the Team

There are plenty of agile tools out there and we’re not experts in all of them so we’ll leave it to you to decide what works best for your business. But here at the Ranch, we’re big fans of Atlassian. We use Jira and Confluence extensively across all of our projects. The out of the box (OOTB) setup in Jira works well for most teams, and you can always add columns for peer review, client review, or additional testing. 

Confluence works well for project documentation like working agreements, retrospective notes, technical specs, and other details that relate to the entire product. Atlassian has an extensive training library you can put to use!

Establish Your Sprint Cadence and Ways of Working

At Big Nerd Ranch, we typically start with two-week sprints and then adjust based on the needs of the team and the project. Within those two weeks, we’ll host all the standard sprint ceremonies. 

It’s a good idea to check in with your team on their schedules. Do they like to have all their daily meetings back to back or spread out across the day? Do they have certain days that are more flexible than others? Do they prefer mornings or afternoons? 

After we establish our sprint ceremonies, we also like to discuss ways of working and team agreements. This includes discussions around protected time (Do team members have certain days with childcare needs? Do they need time for prayer?), expectations for communication and meeting attendance, how we’ll set up our project tracking tool, how we’ll write user stories, etc. This is a lot to cover in one meeting so feel free to break it up over the course of a few weeks. 

Sometimes it’s helpful to establish the basics first, go through a few sprints, then regroup to fill in gaps and discuss weak points. The beauty of agile is there’s always room for process changes based on team needs, product requirements, and the dynamics of your business.

Establish KPIs for Success

We like to measure (team, not product) success for a few reasons. KPIs anchor the team to a unified vision. If everyone knows what’s being measured and why they can align their work accordingly. 

Second, KPIs also support the story you are sharing with your leadership and/or your client. This will be especially critical as you are refining the new process in preparation for rolling out agile to the entire organization. Some KPIs you may want to consider are velocity, sprint burndown, and cycle times. 

It’s especially great if you can demonstrate improvement from your previous waterfall efforts vs agile. Also, one note, consistently missing your KPIs may also be a sign that your team is ready for a change in process.

Refine, Refine, Refine

Once you’ve gone through several sprints with your beta team, take a step back and evaluate. What’s working? What’s falling flat? You may even consider hosting a project retrospective (instead of a sprint retrospective) to get team feedback. Use this input to refine your agile practice (be sure to document everything), so that you’re prepared to roll out to a larger group. 

Once you’ve got a good process in place (and this may take a while), engage with other champions of agile who can support a larger rollout across the business. They can help with training, answering questions, and setting a good example of agile best practices. 

You’ll always have some naysayers; it’s natural for there to be some resistance. For those people, we’d recommend revisiting the second step, where you explain Agile and highlight the pros, sharing the improvements you’ve seen via your KPIs. 

No business or culture is exactly the same and it’s likely you’ll need to adjust some of the above steps to suit your needs. If you get stuck somewhere, Big Nerd Ranch is always here to help! 

The post How to Transition Your Team from Waterfall to Agile appeared first on Big Nerd Ranch.

As Benjamin Franklin said, “By failing to prepare, you are preparing to fail.” Without a plan in place for how your team will accept new work and prioritize, backlogs will become overrun, sprints will lack focus, and there will be a lot of work in progress without a goal for completing features and releasing them to customers. Thinking about what’s next and acknowledging that your team can’t work on everything at once and still deliver value to your customers is key.

While it’s not uncommon to have many things fighting for attention, it is important to prioritize those items so that the delivery teams can focus on them. Often in sprint ceremonies, we hear that there are five or more priorities that lack focus and timing considerations. By providing clarity, you are smoothing delivery. 

Similar to the way having too much work in progress can impact delivery, continually shifting priorities leads to a lack of focus and slowed delivery. One way to avoid this is to establish goals and communicate them to stakeholders, the team, and potentially even your customers—hence, prioritizing them. Establishing key priorities helps to ensure that the right things get done at the right time, and that other deliverables don’t slip through the cracks. It also helps everyone stay on track by maintaining the prioritization of your backlog. 

Focusing delivery on what matters most, and what will bring the most value to customers

When you’re thinking about what can be accomplished in a sprint, release, or quarter – those goals should be customer-focused. What will bring the most value to your customers? What are they waiting on? What surprises do you have ahead and are there any key deliverables that have due dates (contracts, events, etc.)?

As we walk through the different prioritization methods below, these are the things that you should be thinking about. Remember not to make assumptions around what your customers expect and value. When it comes down to it, the only way to understand your customers is to get out and speak with them. Understanding your product is knowing your customers and what problem your product solves for them. 

So, how do you manage prioritization and what are the best methods to figure out what’s next? Below are two methods that work well. At the end of the day, which will work best for you comes down to how you and your team work. Like iterating on a product to find the best features, iterate and find the best process. 

Stack Ranking

Stack Ranking is the most basic prioritization method. It consists of simply starting at the top of the backlog and prioritizing each item, one at a time. 

To Stack Rank your backlog, start by reviewing the first backlog item, just to get a feel for the “ask.” Then take a look at the second backlog item. Is the second item more important than the first? If so, move it above. If not, leave it where it is and move on to the next item. Proceed this way until you get to the bottom of the backlog. 

When weighting the items things that should be considered include: 

• value to the Customer 
• legal requirements 
• deadlines 
• and dependencies. 

Items that are high-value to your customers should be the priority. Contractual, legal, and security items also take precedence. When considering priority, don’t forget timing. If there are any contract deadlines or events that may be planned these must items take precedence. The final consideration is if one item requires another for completion, the item that it is dependent on is a higher priority.

While Stack Ranking can be done alone, pulling in the team and stakeholders will provide perspective and ensure that prioritization considers the product as a whole and not just one perspective. Of course, the more participants the higher the cost. Before meeting with the team and stakeholders, make a few initial passes, prioritize and group similar work items in the backlog. Grouping will allow for a more efficient Stack Ranking process. If similar items are together, they can also be moved together as you work your way through the backlog.

While this may sound tedious, what is great about this method is that when you reach the bottom of the backlog, you are done (at least for now). The backlog is now in order and by making a conscious effort to keep it that way you’re setting the product up for success. 

MoSCoW method

The MoSCoW method hails from Rapid Application Development. With this method, items are grouped into one of four categories: must haves, should haves, could haves, and won’t haves. 

• Must Have – Items that must be included in the product. These are the items required for Minimum Viable Product (MVP).  Without them the delivery would be considered a failure. 
• Should Have – Items that are not required but are expected. These items are not as important as Must Haves but aren’t far behind them. 
• Could Have – If there is time and budget, these items could be included. They are not as important as Should Have items but would bring value to your customers. 
• Won’t Have – Items that will not be included. This doesn’t necessarily mean that the item will never be complete. But at this point in time, these items are not a priority and will not be included in the upcoming releases.

To begin with, the MoSCoW method, determine how you will flag which group each item belongs to. How you do this will depend on your backlog tool. You will want a way to filter and search for each category. If labels are available and searchable, this is the best method. Another way could be to use a priority or stack rank field by assigning a priority/stack rank to each of the four groups. 

Once you’ve established how to group the items within the constraints of your backlog tool, next work through the backlog labeling each item with either Must Have, Should Have, Could Have, or Won’t Have. When all backlog items have been categorized, group them by their category and move them into the appropriate order with Must Haves first, Should Haves second, and so on. 

Now comes the part that takes discipline, for each category use stack ranking to prioritize the items. Take a look at only the items in each group and decide which is most important. Then what comes next. 

You may be thinking, “If these are all Must Haves, does it matter?” Yes, it matters. The backlog order will be the order in which items are picked up and implemented. For Must Haves in particular, dependencies and complexity should be considered, as well as what is most important. The most important items should always be addressed first. If for some reason you were to run out of time for the next delivery, would you want an unexceptional Should Have released instead of a Should Have that will delight your customers. 

These are the decisions to be made. Similar to Stack Ranking this is an exercise that can be done alone but gains perspective when stakeholders and the team are included. So these meetings are not long and arduous, start with the grouping exercise. Then in a separate meeting stack rank within the groups. This may take time but once complete you’ll have an organized backlog that will be ready for not only the current release but also future release planning. 

Continue Setting Yourself up for Success

Once you know what’s next, it is easier to discuss new work and timing. After completing the prioritization process, don’t just let that hard work fall away. Set yourself up for success by prioritizing new items as they come in. At the end of every sprint, check in to ensure the work planned for the next sprint still aligns with the current priorities. 

Once a release or quarter, check-in with stakeholders and the team to ensure that the backlog priorities are still on track. Frequently touch base with customers to gain feedback and find out if there are any new problems to be solved. This will ensure that you’re working on those items that are most important and will bring the most value to customers. 

The post Why Prioritization is Important and How to Best Prioritize Your Backlog appeared first on Big Nerd Ranch.