top
Sort by :

Best Practices When Using JIRA

The Atlassian product suite is most commonly used by IT companies to define requirements and track issues in their Agile projects. However, teams often have questions around what are the best practices of managing requirements using JIRA and Confluence. In this article, I will be discussing how to add different types of requirements on JIRA and discuss a few best practices for managing the same. Creating requirements on JIRA The ‘Create’ option on JIRA opens up a pop-up window that allows the team member to create an issue as indicated in the image below.  The starting point for adding any set of requirements is to first add business requirements as Epics. The user can also add requirements as features or user stories. Changes to requirements can be added as improvements, incidents, ideas or even as a bug. JIRA also provides the possibility to add test cases and test scenarios also as issues that helps better manage projects heavy on assurance of solutions. Epics added will appear on the left side of the screen as indicated above. The user can expand on each epic and view issues added as user stories, tasks etc. under that epic. The user may also directly create a story under a particular epic by selecting the Create Issue in Epic option.  Epics in traceability wth atlassina JIRA will be colour coded and a tag will appear against each issue allowing the user to easily identify to which epic a particular issue belongs. This helps teams group related issues together to better manage the progress of feature groups identified as epics. When adding issues in JIRA the team members can add a lot of information about a particular issue. Below is a small discussion about these aspects and on how JIRA supports the same.  Every issue will need to have a summary explaining the issue, type of issue, priority of the issue, due date, a person to whom the issue is assigned, who created the issue etc. Similarly, the team members can mention which environment the issue appears in or needs to be fixed on and the acceptance criteria for the issue added as a description.  The team members may also specify the complexity or size of an issue in story points or specify the effort required to complete the issue. The team may tag epics to which a particular issue belongs and in addition to that add any supporting materials as attachments.  Issues may also be tagged to a sprint or just be kept on the backlog for future development. Labels added to issues can be used as tags to assist with searching issues in the future. Tasks and subtasks can be added under issues/stories created in JIRA. This is possible by selecting the Create subtask option from within an issue in JIRA as shown on the image below. One of the common problems teams face in terms of requirements on JIRA is with regards to the following. There are lots of instances where issues go beyond the duration specified for a particular sprint. Similarly, multiple subtasks need to be completed in order for a story to be marked as a sprint. It is fine if all subtasks added under a story can be completed during the said sprint. However, more often than not it is not the case and tasks get overrun. Similarly, there are stories or issues which may run for months together where multiple long-running subtasks need to be completed for a story to be marked as done. How do we handle this in JIRA? Is it reasonable to keep on creating the same user story over and over again whenever a related subtask needs to be created? Is it a good practice to keep on forwarding a story to subsequent sprints marking them as not done and let your velocity suffer? JIRA provides a solution to overcome the above dilemma, allowing teams to link tasks to stories.  This allows teams to specify tasks or issues as belonging to, blocked by, cloned by, duplicated by, relates to or as to be tested by another issue in JIRA. Issues or tasks added using the above approach will allow teams to complete and mark these tasks as done without affecting the whole user story which is the parent of it. The parent issue or user story can thus be forwarded to a future sprint without any issue. Discussed above are some of the best practices in managing issues in JIRA. If used intelligently, JIRA can be a very powerful tool to manage Agile projects.  
Best Practices When Using JIRA
Rumesh
Rumesh

Rumesh Wijetunge

Chief Innovation Officer - Zaizi Limited, Chief Operating Officer - LearntIn (Pvt) Ltd., Director /

Rumesh is an IT business leader with over 12 years of industry experience as a business analyst and project manager. He is currently the CIO of Zaizi Limited, a UK based data management company heading the operations in Sri Lanka, the COO of LearntIn, a global training institute based in Sri Lanka and is also a lecturer / trainer at multiple private universities on management, IT, business analysis and project management subjects. He is the current president of the IIBA Sri Lanka chapter and is one of the most qualified and sought after trainers in Sri Lanka. Refer his LinkedIn profile for more details and to see more articles he has written on linkedin

Best Practices When Using JIRA

The Atlassian product suite is most commonly used by IT companies to define requirements and track issues in their Agile projects. However, teams often have questions around what are the best practices of managing requirements using JIRA and Confluence. In this article, I will be discussing how to add different types of requirements on JIRA and discuss a few best practices for managing the same. Creating requirements on JIRA The ‘Create’ option on JIRA opens up a pop-up window that allows the team member to create an issue as indicated in the image below.  The starting point for adding any set of requirements is to first add business requirements as Epics. The user can also add requirements as features or user stories. Changes to requirements can be added as improvements, incidents, ideas or even as a bug. JIRA also provides the possibility to add test cases and test scenarios also as issues that helps better manage projects heavy on assurance of solutions. Epics added will appear on the left side of the screen as indicated above. The user can expand on each epic and view issues added as user stories, tasks etc. under that epic. The user may also directly create a story under a particular epic by selecting the Create Issue in Epic option.  Epics in traceability wth atlassina JIRA will be colour coded and a tag will appear against each issue allowing the user to easily identify to which epic a particular issue belongs. This helps teams group related issues together to better manage the progress of feature groups identified as epics. When adding issues in JIRA the team members can add a lot of information about a particular issue. Below is a small discussion about these aspects and on how JIRA supports the same.  Every issue will need to have a summary explaining the issue, type of issue, priority of the issue, due date, a person to whom the issue is assigned, who created the issue etc. Similarly, the team members can mention which environment the issue appears in or needs to be fixed on and the acceptance criteria for the issue added as a description.  The team members may also specify the complexity or size of an issue in story points or specify the effort required to complete the issue. The team may tag epics to which a particular issue belongs and in addition to that add any supporting materials as attachments.  Issues may also be tagged to a sprint or just be kept on the backlog for future development. Labels added to issues can be used as tags to assist with searching issues in the future. Tasks and subtasks can be added under issues/stories created in JIRA. This is possible by selecting the Create subtask option from within an issue in JIRA as shown on the image below. One of the common problems teams face in terms of requirements on JIRA is with regards to the following. There are lots of instances where issues go beyond the duration specified for a particular sprint. Similarly, multiple subtasks need to be completed in order for a story to be marked as a sprint. It is fine if all subtasks added under a story can be completed during the said sprint. However, more often than not it is not the case and tasks get overrun. Similarly, there are stories or issues which may run for months together where multiple long-running subtasks need to be completed for a story to be marked as done. How do we handle this in JIRA? Is it reasonable to keep on creating the same user story over and over again whenever a related subtask needs to be created? Is it a good practice to keep on forwarding a story to subsequent sprints marking them as not done and let your velocity suffer? JIRA provides a solution to overcome the above dilemma, allowing teams to link tasks to stories.  This allows teams to specify tasks or issues as belonging to, blocked by, cloned by, duplicated by, relates to or as to be tested by another issue in JIRA. Issues or tasks added using the above approach will allow teams to complete and mark these tasks as done without affecting the whole user story which is the parent of it. The parent issue or user story can thus be forwarded to a future sprint without any issue. Discussed above are some of the best practices in managing issues in JIRA. If used intelligently, JIRA can be a very powerful tool to manage Agile projects.  
Best Practices When Using JIRA
Author Image
Best Practices When Using JIRA

Best Practices When Using JIRA

Rumesh Wijetunge
The Atlassian product suite is most commonly used by IT companies to define requirements and track issues in their Agile projects. However, teams often have questions around what are the best practice...
Continue reading

Struggles of Becoming Agile

With the ever-shrinking timelines for delivering technical solutions, more and more IT companies are now compelled to shift from traditional delivery models to more Agile delivery approaches. Organizations are expected to quickly make the said transition in terms of their processes, practices, tools, and techniques while being capable of delivering more with an exact number of resources or even less. Transitioning into Agile delivery approaches is no easy task. Organizations and teams tend to struggle to make the necessary changes. So, what are some of the pertinent challenges in transitioning into Agile? Strategic misalignment Consider a plump of baby ducklings swimming in the water following the mother duck. The ducks will follow the mother duck following her cry. The mother duck sets the direction and sets an example by leading the team. If at all the mother duck loses focus the little ducklings go astray. An IT services delivery company shifting to Agile is exactly the same. The strategic objectives of the organization must directly be linked to the tactical decision of doing delivery using Agile approaches. Often what happens is that the C-level executives suddenly hear the latest buzzwords from the industry and blindly try to implement them within the company. If the leaders themselves embrace the principles and values in Agile and then motivate the staff in following the same, then the application of the new approach becomes more fruitful.  I once worked in an organization where the CEO of the company was one of the first individuals to become a Certified Scrum Master (CSM®) from the company. This ensured that the CEO himself understood the terminology and the dynamics in following Scrum and was better able to even onboard customers to get their solutions done using an Agile delivery approach. Receptiveness to change The success of any change depends on how receptive the individuals are for that change. Agile demands teams to move away from being process oriented to being more focused on collaboration, communication, and continuous improvement. Organizations who have been used to running projects in waterfall approach with well-defined plans and with tight processes often find it difficult to move away from their comfort zone.  Agile demands just enough documentation to execute projects and expects teams to figure out things on the go. Teams must be more hands on and be prepared to experiment and be ready to fail.  Clients too need to adapt to these changes by first being onboard to Agile contract types of Time & Material models and be receptive for a continuous definition of requirements and ever-evolving solutions. ‘We’ vs ‘I’ One of the common problems which most of the teams have is with regards to ‘groupthink’ and the ‘dominator’. Teams often tend to go with the ideas of the consenting majority even when an idea given out by one single individual seems most plausible. Similarly, there can be one person in the group who can be dominating and be able to influence the entire team.  Another side of this problem is where teams expect one person to be the superhero and be responsible for taking up a task and completing it all by himself. This is the traditional waterfall approach where the assignee is expected to be the sole owner of a task. Agile begs team members to be different where individuals are expected to pitch in whenever a task is pending or whenever a team member is stuck and be able to provide a solution to take the team forward. Thus, Agile teams are expected to be self-organizing and self-healing. This requirement for change in mindset often leaves new Agile teams scratching their heads for answers. In conclusion, a shift from traditional approaches to Agile requires shifts in the mindsets of both employees as well as the leaders. It is often a matter of getting the basics right and getting the consent of everyone to follow suit. However, this often is the toughest part in transitioning to Agile!!  
Struggles of Becoming Agile
Author Image
Struggles of Becoming Agile

Struggles of Becoming Agile

Rumesh Wijetunge
With the ever-shrinking timelines for delivering technical solutions, more and more IT companies are now compelled to shift from traditional delivery models to more Agile delivery approaches. Organiza...
Continue reading

A critical analysis of ‘Functional’ Project Management Organizations

One of the main dilemmas any organization faces when setting up their project team is on making the decision of project composition. Often the organization’s leadership ends up stressing over how to resource the project team.  As we all know a project is a temporary endeavor undertaken to produce a unique product, service or a result. Projects can be undertaken by organizations in any business domain, for any specified duration, in order to achieve a set of goals and objectives. So, the organization may decide to form the project team based on the factors mentioned above. Types of Project Organizational Structures The main three types of project organizational structures are as follows. Functional organizational structure Project-based / Projectized organizational structure Matrix organizational structure A Matrix Project Organizational Structure can be further classified as Strong matrix, Weak matrix and Balanced Matrix based on the authority and power shared by the functional manager and the project manager. The purpose of this article is to discuss a Function-based project organization structure in detail. So, I will keep the discussion on Projectized and Matrix Organization structures for a later date. What is a Functional organizational Structure? A Functional project organizational structure consists of project team members allocated from different functional units of an organization. A typical organization would have different functional units such as- HR, Finance, Marketing, Sales, Operations, IT, Administration etc. Each unit will be managed by a functional unit/business unit head who would be reporting to the strategic leadership of the organization. In a large organization, the functional unit heads may have functional managers or operational leadership-level managers working under them who in turn would have a team of executives reporting to them. For example, the HR business unit may have a head of HR, under whom there may be multiple HR managers who are responsible for different aspects of human resource management such as recruitment, performance management, training etc. There will be HR executives working with the HR managers to achieve the objectives of the HR division. Thus, functional organizational structures are to be managed using the current organizational hierarchical structure A temporary team assembled using team members from different functions are formed once the project begins. Project execution in this structure requires the involvement of different functional units. Hence, the different functional unit carries out various components of the project where each unit is responsible for completing a particular component.  Project coordination in this structure normally happens at the functional management level. It is not mandatory that all units in an organization are represented. Staff will be allocated from units only as per the requirements of the project. Advantages of a Functional Organizational Structure A functional project organizational structure is more suitable for projects that require a greater deal of technical expertise. The organization’s leadership has the flexibility in selecting the personnel for the project. Each functional unit involved in the project may nominate resources based on the priority and importance of the project for their unit. The project is like a temporary home for the staff member. Once they complete the project work they have a permanent home to come back to, which is the functional unit.  The staff member though allocated to a project still reports to his or her functional manager. Thus, the staff member’s performance is still tracked and taken note of, thus resulting in better performance evaluations and an uninterrupted progression in one’s career. Organizations often face the issue of key staff members leaving the company while a project is in progress. A functional organizational structure reduces the risk of such turnover with the functional manager being able to easily replace a resource with an equal or better resource in order to ensure continuity of the project. And now the disadvantages… The main issue with a functional organizational structure is to do with the priorities of the staff member. The staff member while working on the project has to worry about day-to-day tasks in the functional unit. Thus project responsibilities may be missed or ignored, resulting in delays or issues with quality in terms of project deliverables. The team member’s allegiance and interest may still lie with the work in the functional unit and not in completing the project work. This may negatively impact project progress. Projects often work with constraints and limitations. Similarly, there are a lot of dependencies that need to be properly coordinated for a project to be successful. Collaboration among staff members from different functional units is a key problem faced in this sort of an arrangement. If a staff member from functional unit A needs to solve a problem which involves a staff member from functional unit C, the problem must first be taken up by the manager of A, who must then coordinate with the manager of C who may reach down to the staff member in C to get the relevant information and then relay it back along the same path back to the staff member in A. This as we see is a tedious task and may result in delays and unwanted stress on the part of staff members. Functional organizational structures often result in a lack of motivation, interest or belongingness among team members and a lack of urgency to complete tasks. They normally end up feeling that a project is just an additional burden that will have no impact on their career progression. Finally, a functional organizational structure is a great mechanism to use when dealing with projects that span multiple functional units and which require specialized technical expertise to complete tasks. Hence, this method must be used sensibly when forming project teams within an organization.  
A critical analysis of ‘Functional’ Project Management Organizations
Author Image
A critical analysis of ‘Functional’ Project Management Organizations

A critical analysis of ‘Functional’ Project Management Organizations

Rumesh Wijetunge
One of the main dilemmas any organization faces when setting up their project team is on making the decision of project composition. Often the organization’s leadership ends up stressing over ho...
Continue reading

Business Analysis Work Products and Deliverables

Business Analysts get involved in projects from the inception till the end and produce different artifacts.  In some cases, the Business Analyst’s involvement begins prior to the project inception in the pre-sales and feasibility stage and go beyond the project’s end into the operations and maintenance phase.  The artifacts BAs create at different stages are different and not all of them get presented to clients or other important stakeholders of the project. It is important to understand the rationale and timing for creating such items as well as understand how they differ based on the project approach. The BABOK® defines two major categories of artifacts. They are work products and deliverables. What is a work product? The BABOK® defines a work product as:  “A work product is a document or collection of notes or diagrams used by the business analyst during the requirements development process.” The business analyst identifies the needs and wants of the stakeholders during the requirements elicitation process. Requirements are not normally readily available like fruits on trees. The business analyst needs to ‘bring forth or draw out’ requirements from stakeholders using various elicitation techniques. Though requirements available in documents or on existing legacy systems can be ‘gathered’ the real underlying needs of stakeholders can be identified by techniques such as interviews, observation, prototypes, focus groups and , workshops. The Business Analyst must be competent enough to quickly document the data and information identified during such elicitation sessions. The BA may capture these pieces of information as meeting notes on a notepad, a scribbling on a piece of paper, notes on a whiteboard, an audio or video recording, photographs, status reports, presentations or even some diagrams drawn using some tool to quickly capture stakeholder needs.  A work product may or may not end up becoming a deliverable. The BA may grow the work product and structure it in a manner presentable to the stakeholders and thus make it a deliverable. In addition to documenting elicited requirements, a work product may be used to share information with stakeholders, share status reports among many other reasons. What is a Deliverable? The BABOK® defines a deliverable as:  A deliverable is any unique and verifiable work product or service that a party has agreed to deliver. A deliverable is a particular output that a business analyst creates as part of the underlying competiting business analysis activities. The BA may decide to use the work products to create these deliverables.  Business Analysis Deliverables are normally identified during the business analysis planning stage and get included in the project management plan as well.  The deliverables, the acceptance criteria, the level of detail, the level of formality, frequency etc. are normally agreed upon up front and sometimes get tied with project milestones. Business analysis deliverables in plan-driven projects are normally formal, and are created using organization specific documentation templates. Deliverables in change-driven projects will be less formal and may even be captured in requirement management tools such as JIRA and confluence. Some business analysis deliverables include the business analysis plan, requirements management plan, business requirements document, system requirements specification, product backlog, business analysis communication plan etc. For example, an SRS document created as a deliverable may contain process diagrams, use cases or user stories, data dictionaries and prototypes which may even be work products on their own. Why should the BA know the difference between the two? It is very important for the business analyst to understand the difference between a work product and a deliverable. A work product may be work in progress, unstructured and very confusing if shared with a stakeholder. A work product must only be used as a means of collecting or presenting information and should not be considered as a final product for delivery until properly structured, detailed out and reviewed.  So, make sure that you understand the difference between the two and use these two wisely to elicit, analyze and document requirements for your projects.  
Business Analysis Work Products and Deliverables
Author Image
Business Analysis Work Products and Deliverables

Business Analysis Work Products and Deliverables

Rumesh Wijetunge
Business Analysts get involved in projects from the inception till the end and produce different artifacts.  In some cases, the Business Analyst’s involvement begins prior to the project in...
Continue reading

Core Business Components in Business Analysis

In today’s competitive world, the role of a business analyst has become one of the key elements for any business entity. In order to understand the role of a business analyst it is imperative to, first of all, understand what a business is and about the complexities involved in operating a business entity. The definition of a business analyst as described in the BABOK® can be decoded as follows. What is a business? Let’s start with the fundamentals. What exactly is a business and why do business entities exist? A business organization is any entity that takes in inputs (financial or non-financial resources) and converts them into outputs through various business processes.   Inputs can be human resources, capital, raw materials, WIP products, knowledge and any other form of resources. A process is a set of interrelated activities that are carried out by a business in an organized manner in order to convert the inputs to outputs. Processes within an organization may include functions such as HR, Finance, marketing, sales, operations, IT etc. where each function will have their own set of processes. Outputs can be products, services or results. Products are intangible and have a set of characteristics, features, and behaviours that satisfy certain needs of stakeholders. Services are intangible but they too have features or characteristics that add value to customer expectations. A result may be a change in a condition or a capability. For example, it can be a change in a process within an organization to make the process more efficient, a change in a working environment, a change in an organization culture / structure etc., the addition of new business units, improvement through the addition of new technology / systems etc. The expected outcomes are more strategic and long-term. These are defined as goals and objectives, which the functional units of organizations work towards. A goal is long-term and is defined for one year or more. Several objectives may make up one goal and are more short-term in nature and can be assigned as responsibilities of different business units. For example, the organization can have a goal of increasing market share by 20% within a 1 year time period. In order to do that, the HR department can have an objective of increasing sales headcount by 10 and ensuring everyone has undergone proper sales training within a 6 month time period. The business Context This environment within the organization (different business units, functional units, and the employees) is known as the ‘MICRO’ or Internal Environment. MESSO environment consists of immediate inbound and outbound logistics service providers in the supply chain (which includes suppliers, supplier’s suppliers, customers (wholesalers, retailers etc.) and their customers). ‘MACRO’ a.k.a external environment consists of the external stakeholders including government, regulatory bodies, technology service providers, competitors, partners, vendors, etc. It is important to analyze these environments to understand how they influence a business. These entities in the business context (business environment) are all known as stakeholders (individuals or groups that influence (impacts) or have an interest in the organization. The influences they make are known as constraints or limitations posed by the organization. Why businesses exist?  Businesses operate with the motive of improving on its current state. No organization intends to operate at the same level all the time. Organizations strive to make sure that the improvement on the current state is always positive and not a loss. The positive change can be financial (in terms of increasing profitability, shareholder value) or non-financial (increase in market share, customer satisfaction, increase in company size, etc.). In order to enable this growth, the organization must undergo change. This change is to do with addressing business needs (business problems or opportunities). Problems & Opportunities A business problem is some limitation within the organization or from the environment that is hindering the progress of an organization. For example the lack of human resources, lack of knowledge and skills, unavailability of modern equipment or technology, inefficient processes etc. can be problems that organizations face. An opportunity is some area which the business has not still ventured into, but one that can have a positive influence on the organization’s fortunes. For example investing in new technology, R&D for new products etc can be such opportunities. Finally, What is Business Analysis? The BABOK® version 3.0 defines Business Analysis as follows. Business Analysis is the practice of enabling change in an organizational context, by defining needs & recommending solutions that deliver value to stakeholders.  So, we see that a business analyst is someone who studies the business and its operations along with the environment which it operates in as mentioned above and generates solution options to needs and wants of stakeholders to enable the expected positive change in the organization. Hence, we can see that it is imperative to understand the business in its operational context before analyzing the same and giving solutions.  
Core Business Components in Business Analysis
Author Image
Core Business Components in Business Analysis

Core Business Components in Business Analysis

Rumesh Wijetunge
In today’s competitive world, the role of a business analyst has become one of the key elements for any business entity. In order to understand the role of a business analyst it is imperative to...
Continue reading

Brainstorming – Promoting Creative Thinking Among Teams : Project Management

BABOK™ version 3 defines brainstorming as a technique intended to produce a broad or diverse set of options. The PMI-PBA® guide defines “Brainstorming” as a data gathering technique that can be used to identify a list of ideas from a diverse group of individuals in a short period of time.  Brainstorming is a great method to promote creative thinking about a business need. During brainstorming a group of people meet to generate ideas around a specific area of interest or a topic or problem with the participants encouraged thinking freely and moving into new areas of thought. Thus, these areas of interest can be related to problems, opportunities, solution options, stakeholders, risks, features etc. Brainstorming is best applied in a group since a key objective of using this technique is to draw upon the experience and creativity of individuals participating in the brainstorming session. There are instances where a brainstorming session is run by a single individual when there is no group setting. The individual may let his or her mind run wild but in a controlled manner in order to generate as many ideas as possible. Steps of a brainstorming session The BABOK® describes three main aspects to run a successful brainstorming session. 1) Preparation Normally a facilitator who has some sort of interest in the topic leads a group brainstorming sessions. The facilitator will first of all plan for the session by identifying the participants, their roles, the area of interest to be taken up for discussion, methodology for idea generation, evaluation and documentation along with time and other resources required for the session. 2) Session The facilitator will then get ready for the brainstorming session by setting up the meeting, inviting participants, defining the agenda and by organizing the required logistics on the day of the session. The facilitator must set the ground rules for the session and encourage everyone to participate in creating ideas. The ideas generated must be recorded in some form (white boards, sticky notes, on paper etc.), group similar ideas together by using affinity technique and select most suitable or preferred ideas using voting methods (dot voting, weighted criteria). The selected idea(s) may be built upon further where the team may brainstorm even further amidst the guidance of the facilitator. 3) Wrap-up During the wrap-up of the brainstorming session, the facilitator may count the votes, finalize the detailed ideas elicited during the session, document them in a format that can be shared among participants and other stakeholders and then finally share the results among stakeholders. Ideas may also be generated for further evaluation and discussion during future brainstorming sessions. Brainstorming session types There are different types of Brainstorming as defined in the PMI-PBA® guide. 1) Free-Form A free-form brainstorming session gives freedom to the participants to contribute to the discussion of their own accord. The facilitator poses the idea or the problem to be discussed where anyone participating in the discussion is given the freedom to contribute at any point in time. A free-form brainstorming session may get chaotic when discussing highly sensitive topics or when it is presided by dominant participants. Similarly, the more conservative participants may be silent and not be willing to contribute thus resulting some key ideas been left out. 2) Round Robin Round Robin brainstorming sessions help overcome issues in free-form brainstorming sessions where each participant in the discussion is allowed to voice his or her opinion. Each participant is given a chance to contribute one by one.  If the participant has no ideas,  he or she may just ‘pass’ on the baton to the next participant in the discussion. This method is suitable when the room is full of experts from whom you as the facilitator want to get as much information as possible. 3) Silent Writing / Pencil & Paper Sometimes, introverts prefer to communicate ideas by writing them down rather than voicing them in public. Highly sensitive ideas can also be communicated using this manner. This method allows people to express ideas while maintaining their anonymity. 4) Mind Mapping Mind mapping is a more visual method of brainstorming where the team tries to show the ideas generated in a diagrammatic format.  Mind mapping helps visually represent ideas on a canvas and helps break down complex ideas along with the interrelationships among those ideas. 5 )Nominal Group Technique A nominal group technique is normally conducted in order to generate a few key ideas from a group of Subject Matter Experts. This technique involves a formal process presided by a facilitator who first of all spells out the objectives of the session. The participants build upon the idea and generate more detailed ideas. These ideas are grouped into themes and listed down on a white board. Each participant is able to clarify doubts on any of the ideas listed down. The facilitator then conducts a round of voting, where each participant is asked to vote for ideas in the order of preference. The ideas receiving the highest number of votes are prioritized and decomposed further in order to create a concrete list of ideas. Conclusion Brainstorming is a highly collaborative and useful technique to create team synergy and a conducive environment to generate highly innovative ideas within a very short period of time. If used wisely, it can be a great asset for any organization.  
Brainstorming – Promoting Creative Thinking Among Teams : Project Management
Author Image
Brainstorming – Promoting Creative Thinking Among Teams : Project Management

Brainstorming – Promoting Creative Thinking Among Teams : Project Management

Rumesh Wijetunge
BABOK™ version 3 defines brainstorming as a technique intended to produce a broad or diverse set of options. The PMI-PBA® guide defines “Brainstorming” as a data gathering techni...
Continue reading

More Edges to Business Analysis

Product design and design thinking are major buzzwords today mainly with IT services delivery and product development companies. It is fast encroaching on the job role of business analysts and UI / UX engineers. But is it the same? Will the business analyst role become obsolete? Is there life beyond product design for a business analyst? Is everything lost for a business analyst who failed to ace a product design job interview?  This article intends to clear the air between business analysis and product design and to discuss about the endless possibilities for a business analyst. What does a Business Analysts Do? IIBA® defines the business analyst as anyone performing the role of an analyst in an organization. They further emphasize the fact that it can be anyone playing the analyst role including an HR analyst, finance analyst, market analyst, UI / UX engineer, Quality assurance engineer, legal consultant, management consultant, process consultant and so on. BABOK™ Version 3.0 defines business analysis as follows.  “Business Analysis is the practice of enabling change in an organizational context, by defining needs & recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs & the rationale for change, & to design & describe solutions that can deliver value.” The main objective of any organization is first of all to maintain its current financial position and then to thrive and improve to a more superior state. Organizations face a many a constraint from the environment or the context that they are operating in which may include PESTEL factors and threats posed by the industry as explained through Porter’s 5 forces.  The business analyst is a catalyst that identifies and facilitates this need for change. The business analyst is expected to study the context and the different factors, study the resources and capabilities of the organization along with its strategic objectives to recommend solutions that can deliver superior value to the key stakeholders.  The solution that the business analyst recommends can be a product, service or even a simple change in the business process. So, it is obvious that conceptualizing, defining and designing a product is just one facet of the role of a business analyst. The business analyst can get involved in studying existing business processes of a manufacturing organization, understand the pain points and problems faced on the workflow and suggest solutions to overcome those problems. Similarly, a business analyst may study the trends and patterns in consumption of a brand, study competing alternative products in the market and suggest improvements to the product or the marketing strategy. A business analyst can even be an advocate to a company CEO or the board of directors where he if equipped with sound business and technical knowledge can become a trusted advisor and thereby propose new business opportunities and business cases. So as we can see, there are endless possibilities to play a role of a business analyst. So, Who is a Product Designer? Product design can be identified as a subset of solution design. It stems from the broader concept of industrial design that is the application of concepts of product design in a mass scale. The role of a product designer is to combine their knowledge about business, technology and engineering to design functional products that are useful to the end users. One of the major schools of thought in terms of product design is the Stanford School of design. Product design according to them is the process of empathizing, defining, ideating, prototyping and testing the product. It is a human-centered design process where the design thinker is first of all expected to understand the problem they are about to solve as their own. Through techniques such as persona mapping, user journey mapping etc. the designer identifies and frames the design problem. Then multiple ideas are created to give a suitable solution for the problem the then moves to the stage of prototyping of the selected idea. The workable prototype is demonstrated to the user where actual testing of the product is made with real users and feedback incorporated in a quick and efficient manner.  Hence, we can see that the product designer role is to do with defining and developing a product as a solution to a problem faced by a stakeholder within a certain context.  So in conclusion, do not worry if you are unable to ace your next business analyst interview. You may have failed just one product design related business analysis job opportunity.  Try for other business analysis opportunities that you are interested in. if you are interested in doing product designer type business analysis work now you know one place from which you can get the required information – The Stanford School of Product Design!!  
More Edges to Business Analysis
Author Image
More Edges to Business Analysis

More Edges to Business Analysis

Rumesh Wijetunge
Product design and design thinking are major buzzwords today mainly with IT services delivery and product development companies. It is fast encroaching on the job role of business analysts and UI / UX...
Continue reading

Technical and Domain Knowledge – Is it a must for a Project Manager?

A topic much debated in the recent times is as to whether it is mandatory for a project manager to have technical skills specially related to the business or industry that they work in and whether it helps them successfully manage their projects. Project Management in Summary Project Management is a role with a collection of responsibilities in terms of initiating, planning, executing, monitoring and controlling and closing a project.  The project manager must be able to run these main process areas of a project ensuring delivery of the unique product, service or result that it is intended to deliver within the triple constraints of time, cost and scope.  Hence, project management demands mastery of a different set of skillset altogether. The project manager must be skilled in stakeholder management, scope management, cost management, time management, quality management, resource management, risk management, communications management, procurements management and integration management which are the ten knowledge areas as defined in PMBOK™. In addition to these the project managers must have competencies in people management, collaboration and in project management tools in order to be successful. Project Mmanagers Selection in Oorganizations The selection of project managers varies from company to company. There are organizations that look at the project manager role as a dedicated role. This is most common in large organizations where projects run in traditional plan driven waterfall manner. A dedicated project manager is allocated to plan and manage projects end to end. In smaller organizations that mostly follow change driven agile approaches, project management is considered as a role that can be played by a team member whose primary responsibility is something different. In plan driven projects of large team size and scope the amount of tracking and coordination required is more. Hence, a dedicated resource to manage a project makes sense. In this case the Scrum Master role may be played by an individual whose specialization or primary job role is that of a business analyst, developer or even of a QA engineer. Agile projects are normally consisting of 5 to 9 team members who are expected to be cross-functional and be able to help each other to work as self-organizing and self-healing teams. It makes sense to have a technical resource to play a project manager role in such a team. In addition to the project management approach being used factors such as maturity of the project management practices of the organization, organizational culture, size of the organization and even the industry plays a major role in the decision of selecting a technical project manager. For example, IT companies which do technical research on niche areas often appoint a technical resource to manage the project.  A popular project management article published in www.cio.com is ‘7 must have project management skills for IT pros’ which lists critical skills that a project manager in the IT industry must have. They are, ●    Be highly organized and a good multi-tasker ●    Take charge and know how to lead ●    Be an effective communicator ●    Know how and when to negotiate ●    Be detail oriented ●    Recognize and solve problems quickly ●    Possess the necessary technical skills According to this research,technical skills are just one aspect of the skills required by a good project manager. More pertinent skills are to do with being able to organize and take forward the project while handling difficulties with regards to resources, stakeholders and other project constraints.  Technical vs Business Project Managers It can be argued that a technical project manager will be able to look at the problems faced by team members in a more logical manner. If technical project manager can objectively analyze situations when planning and executing projects and guide team members to solve problems more effectively. Organizations which feel this way may promote their technical resources to play project management roles rather than hiring generic project managers from outside. However, it is important to note that project management is applicable for any industry and they are expected to possess transferable skills.  There is a flip side to the argument as well.  A technical project manager may face difficulties in communicating with business stakeholders or, have difficulties in planning as they would always look at things from their perspective about capabilities. They may have problems in identifying and understanding the bigger picture of the project goals and objectives and how they tie with the business objectives as they may base their decisions only on technology. Some organizations when publishing job advertisements indicate that project managers who have worked in a certain business domains are preferred. It is clear that technical knowledge and business knowledge are equally important for a project manager to have. In conclusion, it is clear that good project managers must have a mix of good business as well as technical skills and be able to adapt and apply these skills as per the requirements and context of the project.  
Technical and Domain Knowledge –  Is it a must for a Project Manager?
Author Image
Technical and Domain Knowledge –  Is it a must for a Project Manager?

Technical and Domain Knowledge – Is it a must for a Project Manager?

Rumesh Wijetunge
A topic much debated in the recent times is as to whether it is mandatory for a project manager to have technical skills specially related to the business or industry that they work in and whether it ...
Continue reading

Incomplete Stories & Tasks in an Agile Sprint

Have you ever encountered a situation such as above? I am sure you have and I am sure that you experience this often. So, how do you deal with it? Does the managers in your company make a big issue out of it? Is it a situation probed intensely by the product owner and even the Scrum Master who is the team’s protector? You need not worry. Below is a discussion on incomplete sprints, better known as ‘Spillovers’, and on how to best deal with them. Spillovers & DoD – The definition Simply put, a spillover is a backlog item that has failed to meet the criteria defined in the Definition of Done (DoD) for the project team. It is important to note that the DoD is defined for the entire project and is applicable for any user story. For example a team may decide that the DoD for a user story is for it to be elicited, groomed, analyzed, designed, UI / UX designed, coded, unit tested, functionality tested, integrated and regression tested. Any story not ticking all these boxes may be marked as not done. Well, not always!! The team may decide that some of these criteria is not applicable for certain stories during sprint planning and those should be evaluated accordingly. Trouble with Spillovers? Spillovers normally surface during Sprint Demo & Retrospective meetings and often give trouble to Scrum team members and product owners during sprint planning. It is the responsibility of the PO to mark a user story as done by going through the DoD criteria. Then only should the story be moved to the ‘Done’ column on your JIRA board. Sometimes the POs end up scratching their heads as a result of poorly defined DoD’s or just pass stories on to Done state just ensure progress. Similarly, during planning teams end up spending a lot of time discussing about these spillover stories and do extensive planning for these unfinished user stories. Spillovers are common phenomena for any agile team. But it is important to analyze the root causes for these spillovers if this happens often.  Common reasons for spillovers Below are some common root causes for unfinished work- Problems with DoD – The DoD was not accurately defined, and you find that out later in the sprint. This results in the argument around marking the story as ‘done’. Overestimation of work for the sprint – The team becomes over ambitious and commits to much more than they can handle. Larger chunks of work eating up on time of other stories. – This is actually not a big issue. Story point estimation is a relative estimation and has no link to time needed in hours. Hence, this overrun of time may happen often. Unforeseen scenarios– There may be situations where a team member becomes unavailable due to sickness, other work commitment or personal commitments. Other situations related to team members not be able to access code repositories due to various environmental elements may also cause delays. Change in priorities – PO may decide to change priority of stories mid sprint or stories may even become higher priority with technical limitations. As a result, stories may not be completed and may get spilled over to subsequent sprints. Dealing with spillovers So it is important to devise strategies on how to manage such unfinished work. Below are some recommendations on how to do so. Again, this is not rocket science but the application of some common sense to make things work. It is important to review the process followed by the team during the sprint retrospective session. This session can be used to identify the root cause for spillovers and to discuss options available to mitigate it. It is important to note that the cause for most delays may be common and thus the team must understand the factors related to delivery delays to quickly move on to discuss other aspects important for project success. The team must discuss on the future of the user story that got spilt over. The PO must decide whether the story is still on high priority or not.  If yes, then simply move the story forward to the next sprint. You have already decomposed the story to the most granular level during grooming and it is just a matter of getting it done. Again, if the story was done partially it is important for the team to discuss the amount of work remaining to mark the story as done. This analysis may actually result in the creation of a new user story with a new acceptance criteria, a completely new DoD and a brand new estimation. If not on priority, simply move the story to the bottom of the product backlog. The story will get evaluated for priority during backlog grooming and be moved up or down the backlog as relevant. I previously wrote an article on capacity planning for agile teams. It makes sense for the Scrum Master to understand the availability of the team for the entire duration of the sprint and plan the amount of work that can be taken up accordingly. For more information on capacity planning and how it may help avoid spillovers refer here Some more logical things to do is to dedicate more time for planning. This may be done by defining a proper goal for the sprint and to ensure that all user stories are aligned with this particular sprint goal. The scrum team may also set aside some buffer time for unplanned work which will give the team some breathing space just in case a story runs for more than planned. So in conclusion, spillovers are to be managed properly. You may never be able to completely eliminate it from your projects. But with proper management and planning, you can reduce the number of times it may occur and be able to reduce its impact.  
Incomplete Stories & Tasks in an Agile Sprint
Author Image
Incomplete Stories & Tasks in an Agile Sprint

Incomplete Stories & Tasks in an Agile Sprint

Rumesh Wijetunge
Have you ever encountered a situation such as above? I am sure you have and I am sure that you experience this often. So, how do you deal with it? Does the managers in your company make a big issue ou...
Continue reading

PMP® - The Foundation for a Career in Project Management

The role of a project manager is to navigate the ‘vehicle’ called project along the ‘road’ called solution roadmap navigating through its ‘bumpy hills and valleys’ called constraints and risks with all project stakeholders on board in order to achieve the end goal with respect to a unique product, service or result. The foundation to project management is the ‘Guide to the Project Management Body Of Knowledge’, better known as the ‘PMBOK®’ or the ‘PM Body Of Knowledge’. Project management entails both an art and a science. The science of project management is defined in the PMBOK® through the concepts, tools and techniques discussed in the ten knowledge areas. Professionals master the art of project management when they work in projects and put these learning into practice.  A project manager who is PMP® certified is considered as someone who has mastered the science of project management and is thorough about the concepts and is capable in properly managing a project through its lifetime. Hence, it is first important to understand one’s purpose to pursue the PMP credential. The primary reason should be not just to pass the exam or to get the credential against one’s name but also to master the concepts in project management, learn about the best practices so that those can be applied to real life projects.  How does PMP® lay the foundation? The PMBOK® guide is structured in a way that it takes the credential aspirant through a journey.  The PMBOK® first of all gives an introduction to the core concepts in project management such as what a project, program and portfolio is, what are project approaches, what is a project life cycle and on how organizations structure themselves to execute projects.  The core of the PMBOK® is dedicated to taking the participant through ten knowledge areas. Each knowledge area discusses tasks, concepts, tools and techniques relevant to each topic.   The material on stakeholder management equips the project manager with key knowledge on stakeholders and on how to identify and manage them. The scope management knowledge area discusses ways to define the scope boundary for the project, methods in decomposing the project along with other key concepts in managing scope creep. Project time management examines the activities involved in estimating project effort, defining a project schedule and aspects related to managing project time so that it would not overrun. Project cost management is about identifying cost components for the project, so that the total project cost can be determined. Project quality management discusses concepts related to quality assurance and quality control, verification of project process and validation of product. The human resource management knowledge area debates about the stages in developing project teams, concepts in motivation, leadership and team building and concepts on allocating resources as well as balancing load on resources.  Project communications management knowledge area lists concepts related to identifying, planning for and managing communication among all stakeholders interested and impacted by the project. Projects don’t always run smoothly but are prone to risks and issues. The risk management knowledge area lays the foundation to the key responsibility of a project manager in terms of identifying and managing uncertain events that may affect the project. Most of the elements in a project is bound to change and are known as configurable items. The integration management knowledge area prepares PMP® aspirants with concepts related to identifying and managing changes. Finally, the procurement management knowledge area deliberates about different ways in which contracts can be created and managed and how it may impact project execution. Conclusion The PMP® credential has become a yardstick when evaluating and selecting a professional for a project management job. The certified candidates can be differentiated from others as to be an individual who is knowledgeable and is capable of applying concepts in practice. Hence, a pertinent question at project management interviews is to check whether candidates have the PMP® credential.  So, why wait to get the PMP® credential? Devise a plan to work towards the credential today itself. Identify a training provider and attend sessions to obtain the required contact hours. Then fill in the application form, do your self-studies of reading the PMBOK® guide at least thrice and by attempting at least a thousand sample questions. Good Luck and hope to see you all as part of the community!!  
PMP® - The Foundation for a Career in Project Management
Author Image
PMP® - The Foundation for a Career in Project Management

PMP® - The Foundation for a Career in Project Management

Rumesh Wijetunge
The role of a project manager is to navigate the ‘vehicle’ called project along the ‘road’ called solution roadmap navigating through its ‘bumpy hills and valleys’ ...
Continue reading

SUBSCRIBE TO OUR BLOG

Share Blog

View All Topics

Follow Us