Tag: Team

User Stories and Mapping

Written by Abraham Magalong on July 20, 2017. Posted in Articles. 2 Comments on User Stories and Mapping

User Stories and User Story Mapping are must have techniques for a Business Analyst.

You can do business analysis without SCRUM, but you can’t do good SCRUM without Business Analysis. Story Mapping enables clarity of user stories.

Agile Alliance talks about the benefits of User Stories, “One intent of this practice is to avoid a failure mode of incremental delivery, where a product could be released composed of features that in principle are of high business value but are unusable because they are functionally dependent on features which are of lower value and were therefore deferred to future releases.”

That’s a pretty in-depth explanation, but in general User Stories help create a higher quality product for the customer. Sunit Parekh sees it as more collaborative, “Story Mapping is an engaging activity where all participants are involved in the process of building the product backlog on a wall, versus writing a dull 100-page requirement document.”

In an interview with CIO Magazine Steve Rogalsky with Protegra sees user stories as more visual. “It allows you to see the big picture in your backlog,” says Rogalsky.

User Story Components

According to Mountain Goat Software, “User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.” A typical User Story consists of:

As a < type of user >, I want < some goal > so that < some reason >.

Know Your Stakeholders

Having knowledge of the process enables bringing the identification of stakeholders into the picture. The additional identified stakeholders help validate whether user stories are accurate and will allow the project team to introduce change management activities early. One change management strategy which User Story Mapping encourages is to facilitate stakeholder buy-in. Stakeholder buy-in is vital and benefits the project team as these stakeholders can help develop additional user stories that the project team potentially have missed, elicit business impacts and helps validate design and prioritization discussions.

Requirements Are User Stories

User stories capture requirements and can be used to model a meaningful sequence of user activities, perpendicularly across a prioritized ranking of user stories. The benefit of which encourages richer discussion in planning and prioritizing user stories, further engages stakeholder participation, is a mechanism to help understand business impacts and can allow a team to see how user stories affect the customer journey visually.

Story Mapping

Story Mapping is about taking a series of User Stories and putting them together in a meaningful and visual way.

J Patton Associates says, “Story Mapping is the process of arranging user stories into a useful model to help understand the functionality of the system.” This technique allows for the planning and prioritizing of requirements in order of importance and value. The Agile Alliance elaborates story telling a little further, “Story Mapping orders user stories along two independent dimensions. The horizontal axis is depicting the user activities in order of priority or the sequence of process activities and the vertical axis depicting the release or project milestones.”

Once used, story Mapping can enable the project team to dice stories (often at Epic level) horizontally into the main functionality. This horizontal view is important as it visually represents the value stream of the designed solution. This analysis allows the project team to understand the dependencies and highlights gaps for how the created User Story functionality will work. This end to end perspective enhances understanding the customer journey of a person using the solution.

The vertical axis is important as it represents the project teams User Story release plans. Project team centers discussions on which user stories are high value and easy to develop. Leave complex user stories to later releases. This focuses the project team on creating a minimum viable product (MVP) for the customer. Sprint reviews can help fine tune the product and allow the project team to assess User Story release patterns regularly. The vertical positioning of user stories enables the project team to discuss whether user stories are prioritized in terms of need, value, and complexity.

Story Prioritization

Prioritization of User Stories can help build the User Story Map. User Stories seldom keep their same priority throughout the cycle so be prepared to re-prioritize often. High-Medium-Low prioritization sounds easy, but everything winds up as high priority. Use the hot air balloon technique for prioritization. Is this User Story more or less important than this User Story? Comparison of user stories to each other brings out additional discussion on risk and why a User Story is more important to the overall customer experience.

Greater Detail

User Stories are high-level by nature. System Requirement Specifications (SRS) are more detailed and lower level in nature. Depending on the project you might need to use both User Stories and System Requirement Specifications together to create a User Story Map. Thinking about how the User Stories relate to each other in a logical flow for the developer, release to the customer, and other technical, environmental issues will drive putting together a Story Map.

Complex User Stories are typically a good candidate for more technical details. Get details when trying to fit a User Story on the Story Map isn’t making sense. More technical details might help you place the User Story in a better position in the Story Map.

7 Body Language Cues from a Group of Business Analysts

Written by Richard Lannon on July 18, 2017. Posted in Articles.

I was out having coffee with a group of business analysts; we were just chatting about our careers and the various projects we’d worked on over the years.

Then someone said, “Hey, what do you do to read people’s body language?” The statement made me recall a time when I taught Business Analysis Facilitation skills and the great dialogue that would erupt in the class, on the topic of body language. This group of professionals was no different than the people I have taught and coached. We all laughed and started picking out obvious body language choices and commenting on each choice’s interpretation. It was funny watching my business associates adjust their body to change what they were projecting as we discussed this topic.

Crossed Arms

We all know crossed arms is interpreted as a physical barrier that says you are closed off and not interested in what someone is saying. It is also somewhat of a power move. In essence, you are shutting the other person out with crossed arms. I see this one all the time. I sometimes think that people just don’t know what to do with their arms, they could be cold, resting their arms in a stance or maybe they are showing off their biceps. Either way, if you are working with a group of people, you need to know what crossed arms means and how to deal with it.

Avoiding Eye Contact

Guilty as charged. We all do it, even when we know better. When you avoid eye contact is as if you are trying to hide something. That is the general interpretation. It is also possible that you lack confidence or lack interest in the topic you are hearing. I know some people whose culture interprets directly looking into someone’s eyes as inappropriate and disrespectful. Through understanding the situation and circumstance, you need to provide a safe space and permission for someone to look into your eyes. Part of this is to understand the workplace rules of when to look into someone’s eyes. The easy answer is for introductions and when addressing someone. Ensure you consider culture.

Looking Down When You Talk

The interpretation is you are self-conscious and lack confidence. Your words fade, are hard to hear and lose their impact. Focus on keeping your eyes level when making important points or when addressing someone. I am into fitness and workout intensely with various partners. Recently, one of my female peers joined me. She wanted to do more weights for her biceps, so I agreed to spot her. As she was lifting, she turned her head slightly and looked down. Two things were happening: First, she wasn’t confident in lifting the added weight, and second, she was uncomfortable looking towards me. So that she wouldn’t injure herself, I stopped her and told her to pretend that she was in front of an audience and look straight ahead. Interestingly, it looked like she was looking at me, but she was focusing on projecting, using a simple technique to keep her head up and in line.

Playing with Hands, Hair or Whatever

For me, this one is not an issue since I left my hair in the 1990s somewhere. But maybe you play with your rings, or you are always fixing your shirt, pants or skirt. This interpretation varies depending on what you read. You could be nervous, or maybe you had too much coffee that day and the shakes kicked in, or you are anxious and distracted. The interpretation here is that you might be a little vain; concerned about appearance and not enough about your career or the stakeholder. I guess you just have to learn not to fidget.

Eye-Rolling When Someone Contributes

This one drives me nuts as the action states you do not respect the person around you. I have watched this in meetings. People disrespecting someone else, even making faces afterward. It is time for you to grow up and leave your teenage years behind you. A professional knows that eye-rolling is a choice you make, and it is an immature one at that. You can learn to control this action, and it would be worth your while. When you roll your eyes, your peers might smirk, but what they are thinking is “Get a life and grow up.” It is inappropriate behavior.

Providing the Right Handshake

The right handshake is for both men and women. You have to get it right. If your handshake is too weak, you lack confidence and authority, and if it is too strong you come across as aggressive and controlling, or you are over compensating for something. I learned as a child how to shake another person’s hand professionally and personally. Yes, these can be different things depending on the situation. The key word is situational. When you shake a person’s hand, it should be firm but not overpowering, and you should look them in the eyes when you greet them. As you repeat their name or say it’s a pleasure to meet you, acknowledge that person with a slight head nod. If you do it right, you will always make the best impression. If you have a weak or strong handshake, practice doing it right and don’t over-compensate no matter your gender.

Physical Distance Between People

For most people in western society, we know that this is about one and a half to two feet. This rule goes out the door if you have a relationship, are siblings or are on a bus. But professionally, one and a half to two feet is about the right distance to stand away from someone. If you get too close, people get uncomfortable. You need to learn to respect that. Now there are times you need to step into a person’s space, and the rule is to ask permission for that short time. For example, showing someone how to do something may require you to get closer, or maybe you are working on something, and you both need to lean in a bit. Those are understandable situations. But what you don’t do is get into someone’s space and in their face for no particular reason. If you do, the interpretation is you are rude, annoying, aggressive and disrespectful to say the least.

Final Thoughts

These are just some of the body language items that came up during my discussion with my friends during the coffee meeting. Interestingly, each gender and culture has their own perspective on these body language items. Nevertheless, we all agreed that we lived in a western culture where we had to try to factor in a lot of different variables to make an appropriate response to someone’s body language. Now if that doesn’t sound like a bunch of business analysts talking, I don’t know what is.

We are talking profiling here. There is lots of research that suggests that people who are more balanced and have a stronger awareness of themselves tend to be better at reading and responding to people’s body language. They tend to make fewer people mistakes. For years, I have been a strong supporter of emotional intelligence: something I suggest all professionals in the business analysis industry learn about. It will help you to navigate relationships and read body language better. Good luck.

Remember, do you best, invest in the success of others and make your journey count. Richard.

Collaboration, Collaboration, Collaboration

Written by Pascale Weir on June 28, 2017. Posted in Articles.

A good Business Analyst is always focussed on stakeholder management, helping elicit, specify, analyze and manage their needs to help them improve their business.

This is very simple when the Business Analyst is engaged purely for this purpose, and the stakeholders are clear. However, BAs often work as part of a team to assist with implementation of solutions, and in our ever-changing world, where there are more resources working on a project, the BA may overlook the stakeholders who are right under their noses.

Why? Well, the reason is very simple – as part of a team. The Business Analyst often believes and works with the view that a project team is a unit, and that everyone on the project team has the same views and objectives – often forgetting, that each team member on the project is an individual with their views, ideals, and objectives.

Lack of collaboration within a project team can lead to delays on the project due to lack of communication, undefined or lack of expectation management and a lack of or incorrect requirements being elicited. Every member of the project team is an integral, vitally important stakeholder on the project, who needs to be supported, just as much, if not more than all the other “business” stakeholders. The question then arises “How do we manage the expectations and needs of these integral stakeholders?” There are a few ways in which this can be done effectively, and if done correctly, it can contribute to the successful completion of a project.

Using requirement elicitation techniques such as interviews, meetings, and workshops (formal or otherwise), you could identify the needs of the other project team members, and develop a clear understanding of what the benefit of your analysis would be for them on the project. Don’t underestimate the process of discovering, refining, and validating these requirements. These needs are likely to change as the project progresses, so continuous improvement is a core concept for effective team collaboration and productivity. This underpins self-organisation within a team. You can also embrace some of the collaboration techniques. For instance, collaborative games are great at breaking down silos or establishing teamwork foundations. They also drive focus towards working efficiently. Additionally, embracing visual displays allows team members to be constantly reminded about key concepts, and enables open group conversation.

For managing work in progress and dependencies, incorporating Kanban boards and story maps provides a more tangible way for the team to understand what is currently underway and any gaps in business value. These strategies are the same, no matter what kind of project you are working on, waterfall, iterative or agile project. In fact, the more “fluid” the project, the more important the collaboration and communication within the project team.

The key to collaborating effectively in a project team, is clear, factual communication, along with flexibility and adaptability to change. Additionally, respecting others area of expertise will allow team members to communicate and develop an understanding of what the needs are for each of these team members.

Of course, this doesn’t guarantee that there will not be any conflicts or disagreements within the project team, but through using effective communication and flexibility, conflict can be resolved timeously. This allows all the team members to focus on the work to be done to complete the project successfully; business outcomes, on time, within budget and to the satisfaction of the customer.

Product Manager’s Guide to Embedded BI: Empowerment with Self-Service Analytics

Written by Marcus Hodges on May 17, 2017. Posted in Articles.

A product’s roadmap is no secret to its product manager. The job entails planning future development in response to requests for enhancements, new requirements, and competitors’ offerings.

One priority making it to the top of the list for product development is intuitive self-service business intelligence (BI), data analytics, and visual data discovery. End users across a wide range of industries expect these capabilities in the applications they use regularly. Self-service BI helps organizations spot outliers and trends, improve business processes, save money, and grow revenue.

Software Vendors Respond to Growing Demand for Self-Service BI

Software companies realize the benefits of improving analytics in their solutions. Delivering value extends beyond simply offering self-service functionality. It requires the ability to embed analytics in the workflow where users need them to make decisions and to give users the ability to create new reports and dashboards for true data exploration.

However, coding this functionality in-house poses complications:

Lengthy time to market – an analytics project beyond superficial functionality may take years to launch, especially if analytics is not a core competency of the developers tasked with the project
Opportunity costs – resulting from having developers focus on analytics and deferring essential development of enhancements, upgrades, or other changes; licensing of toolkits beyond the use of open source libraries and toolkits adds to the expense line
Ongoing maintenance and enhancements
Scalability – resale requires developing a BI application that is customizable, scalable, and compatible with other infrastructures

Purchasing and embedding an analytics offering from a third-party software company with a core competency in analytics is a more cost effective approach. Many options for embedded analytics products exist in the market today. Understanding the differences between these products starts with scoping:

Functional needs – like self-service, a short learning curve, easy-to-use query functionality, real-time reports and responsiveness across devices
Business needs – project costs and return on investment (ROI), factors associated with selling the solution profitably (licensing, third-party support costs, updates to existing infrastructure requirements, add-on product cost, personnel resource requirements), and long-range organizational issues (growth plans, ability to scale a growing customer base, pricing model for monetizing analytics)
Technical needs – organization’s technology stack, database and other data source technologies, availability of the different technical resources and skillsets needed to support the project (deploying the BI tool in the cloud, on-premise or as a hybrid, or requirements for a data warehouse or changes to an existing database)

Where to Start – Research and Product Demonstrations

Early research takes place using software review sites that offer verified reviews from the user base and studying research reports published by industry analyst firms that specialize in BI. Vendor websites are another source for information. They may include case studies to learn how they handle BI implementations.

An organization will often target three to six vendors for product demos. To narrow down the list of prospective product trials to two or three, an organization can use a comparison matrix to prioritize and track requirements against the different solutions. Demonstrations need not be exhaustive, but there are key takeaways from each:

Does the solution work with the organization’s technology stack?
Does the solution does it have the ability to utilize specific functionality required by the software company, like a particular type of visualization?
Does pricing align with the organization’s budget?
How will the end user experience look?
What will the deployment process entail?

Additional questions might include:

Is there support for arithmetic operations like addition, subtraction, and aggregation?
What database support exists?
Is complete white labeling of the solution available?
Is it fully web-based, or do desktop dependencies exist?
Is there a user interface (UI) for administering tenants and mapping data fields, or is coding required?
How long before the solution is live?
What percentage of customers embed the solution?
What options for monetizing analytics exist?
What have companies charged for it?

Obtaining Value from Trials and References

The next step is conducting the software trial to vet the software against an organization’s key test cases.

The goal of the trial should be to create a core set of analytics deliverables — reports, dashboards, visualizations, and key performance indicators (KPIs) most important to an organization’s customers. The trial allows companies to:

Vet the embedding process and integration
Test how solutions handle user and database security
Determine support for multi-tenancy
Confirm compliance with regulatory standards like HIPAA, SOC2, or PCI

References from other customers using the same software version trialed, and in the same vertical and of approximately the same size are gold. Listening carefully to answers to specific questions can expose red flags. Use conversations with references to obtain clarity into issues that the demo only lightly touched upon, and determine how easy it is to work with the company. Suggested questions to ask include:

How long have you been using this product?
What were the major reasons for choosing this solution? What were your expectations? Has this product met your expectations?
How long did it take to embed analytics? Did you encounter any problems during the process?
Was your implementation on time and within budget?
How many end users are using the analytics solution?
Has the solution allowed you to monetize analytics in your application? What model are you using to monetize analytics?
Did the product require any workarounds?
How much internal IT support was needed for the project? How much support did the vendor provide?
Overall, how satisfied are you with the solution? Would you choose the vendor again?
Was there anything you wish you had known before implementing this solution?

Beta Testing and Phased Roll Outs to Identify Deployment Issues

In addition to trialing functionality and soliciting feedback from others, organizations should assess how well the solution will deploy on existing infrastructure. Organizations may require a scaling strategy, such as scaling up by upgrading hardware and memory or scaling out by replicating servers, adding load balancers or containerizing with a solution like Docker.

It is not easy to predict performance without knowing what to expect of self-service BI regarding usage. Many software companies opt for a soft launch of a beta release to one or two customers. Discounted pricing to beta customers is offset by the value obtained from their involvement in beta testing, which can address issues early on before they become system-wide problems.

Rolling out functionality in stages can help ensure stability. For example, by gradually introducing features, companies can identify potential stresses to application infrastructure from increased demand. Other companies may opt to deploy analytics as a standalone BI portal. A less robust, in-context analytics experience, this is the fastest approach to implementing analytics when speed to market is most important.

Avoiding Licensing Pitfalls

A product’s licensing model is an important factor in ensuring monetization of analytics. Organizations create value with improved analytics in one of four ways:

Selling enhanced functionality as an add-on
Winning new business
Retaining current customers
Reducing service costs

The embedded BI product selected should not lock a company into an unworkable price model. Scaling can dramatically influence overall costs. User- or session-based pricing models can reduce ROI as businesses grow and the number of end users expands.

Organizations should look for a licensing structure that complements the value derived from analytics, is easy to understand, and maintains transparency regarding costs associated as the application scales. When determining pricing, also consider proprietary software, infrastructure enhancements, and ongoing maintenance.

Contract Negotiations

A company’s flexibility and responsiveness during negotiations are excellent indicators of how a company will operate as an OEM partner. Lengthy, drawn out legal processes that outweigh moving quickly to address needs often foreshadow future implementation and services processes.

A list of recommended service partners and suggested service hours can indicate a solution’s maturity and how well it is designed for embedding. Look for a model based on shared value creation. A line item for a discount of any size should call into question the vendor’s commitment to a partnership. Showing a big number is often an attempt to sell value, and then an arbitrarily assigned discount indicates what they believe they can extract as a total cost.

Conclusion

The movement of self-service analytics from a nice-to-have to an application requirement need not be a burden for application development teams. With proper planning, product managers can ensure deployment of a rich analytics interface that helps end users gain more value from data, takes the report creation workload off developers, and allows opportunities for further monetization of the application.

10 Traits of the Indispensable Team Member

Written by Neal Whitten,PMP on March 31, 2017. Posted in Articles.

If you were building a team and could hand-pick its members, what are the key traits or attributes you would look for?

What are the behaviors and actions necessary for them to perform at their best and the team to perform at its best? In other words, what makes a team member valuable and indispensable?

This article reveals a set of key behaviors and actions that every leader would like to see in each of their team members. Of course, members cannot be expected to know already or practice these tenets. These behaviors and actions must be revealed as the team is forming and reinforced throughout the project.

Praise should generously be bestowed on those members who demonstrate these tenets notably. But members not performing to an acceptable level will need coaching and nurturing so they can become proficient as well.

Let’s now look at the behaviors and actions of the indispensable team member.

1. Fully participate

Voluntarily speak up in meetings and get-togethers. Contribute ideas, even if they may be unconventional—many times thinking out of the box brings the team to the best solution. Your opinion is important and can help identify or move an issue closer to resolution. Be forthcoming to both ask and answer questions.

2. Be truthful

Be honest and timely when revealing your progress and issues. When you make a mistake, admit to it and take accountability. When you are faced with making a commitment, make only good commitments.

3. Be reliable

Meet your commitments. Always do what you say you are going to do and when you said you would do it. A team is only as strong as its weakest link—don’t be a weak leak. Consistently provide quality work. Demonstrate personal pride in fulfilling your commitments.

4. Maintain a positive attitude

Adopt a can-do spirit. Be thankful for and even look forward to the challenges and opportunities before you. Place a constructive view on issues—seek out the sun during cloudy and stormy moments. Don’t take or make things personal.

5. Focus on solutions

The most professionally mature members do not engage in finger-pointing and the blame game. Instead, they are busy focusing on solving issues and moving forward. Be a problem solver. Recognize that we all make mistakes and that we need to learn from them and not repeat the same mistakes.

6. Practice being proactive

Don’t just focus on the task at hand, also look at the tasks coming up to help ensure you and your team’s readiness. Make it a standard practice to think one or more steps ahead.

7. Share knowledge

Yes, knowledge is power. But the best performers give it away—they don’t hoard it. They recognize the benefit of this behavior in strengthening the team and raising their own value and reputation in the process.

8. Demonstrate personal initiative

Practice self-reliance when appropriate. Require minimal leadership. Ensure you understand your assignment and domain of responsibility. If you are unsure about taking action, then seek appropriate counsel. Make things happen.

9. Practice continuous improvement

Seek ways to continually improve your skills as well as the processes and procedures that you and your team engage in. Become and remain the subject matter expert in your chosen domain. Be open and accepting of constructive criticism. Don’t just correct a problem; seek to correct the process that allowed the problem to occur. Encourage feedback on your performance. Adapt to change.

10. Promote team success

Place the team first. See yourself as there to serve your team to the best of your ability. Show that you care about the welfare of the team and its success. Look out for the team as if its success is defined by your actions each and every day. Look for ways to make the team and its leader look good.

Shared values

This list could be a great starting point for team discussion as each trait is described and examples shared to reinforce the benefit to each member and the team as a whole. Of course, other traits can be added and discussed. I cannot overstate the importance of a team embracing a set of traits—shared values—that can serve to bond and strengthen the team members along with their journey.

In Closing

I have listed these 10 behaviors and their brief descriptions in a 1-page PDF document that you are free to download and make copies.

Team members who are tenacious and diligent in demonstrating these behaviors and actions will serve as outstanding role models for other members. There’s nothing better than an example to inspire and spur the members of a team to be their best.

Almost all team members want to perform well and to support the success of the team. They want to mimic behavior that will help the team and, in the process, make them look good as well. If you are a project manager or other leader, don’t overlook your personal duty to set a consistent example for your team members.

Now, go become your imagined self!