top
Sort by :

Writing Effective User Stories in JIRA

User stories are one of the main methods of communicating requirements to developers/development team in an Agile project. It is important for the individual tasked with documenting the requirements to be able to write effective and detailed enough user stories. The user stories are required to be comprehensive enough to enable the developer/development team to start analyzing, designing and developing the required functionality, feature or requirement stated in the user story.     This article while intending to guide individuals on how to write effective user stories is also intended to advise on the best practices of creating user stories using JIRA as a requirements management tool for creating stories and tasks. What is a User Story?   User stories are short, simple descriptions of a feature in the system under development told from the perspective of the person who desires this new capability. This person is normally a user of the system or even a customer who pays for the solution.  User stories typically follow a simple template as below. As a <type of user / user role>, I must be able to <some goal / feature> so that I can <some reason / benefit>.  User stories are often written on index cards or sticky notes and pasted on an information radiator or in other words a scrum board. This article is however on maintaining user stories using JIRA and on how the tool can be used to ensure regular conversation.  Writing user stories on an index card is actually the ‘Card’ part of the 3 C’s in user stories. It is said that a user story should be long enough to fit into an index card and be detailed enough to arouse discussion. Writing user stories in JIRA A new user story in JIRA can be created by selecting the option to create a new issue of type ‘Story’ as shown below.  The user story in the format listed above can be written in the summary field of the new issue creation screen.  User story definition should satisfy the INVEST criteria which implies that the user stories should be: Independent (of all other user stories and be able to exist on its own) Negotiable (not a specific contract for features but be able to be used to facilitate discussion among relevant stakeholders) Valuable (create some business value) Estimable (to a good approximation) Small (so as to fit within an iteration) Testable (in principle, even if there isn’t a test for it yet)   Trace your Customer Requirements to user stories in Agile through the integration with JIRA. https://t.co/esXyAJykZy pic.twitter.com/DZoa1tJrjL — Visure Solutions (@VisureSolutions) 21 November 2017   JIRA also provides the option to set priority of user stories which might have been done based on the MoSCoW criteria, due dates, assign the story to a team member of the project, allocate a story point/hour based effort estimation for the story, tag the user story to a component level feature or in other words ‘Epic’ and be able to assign the story to a sprint during which the story is required to be implemented. Adding description to user stories The 2nd C of the 3 C’s in user stories that is ‘Confirmation’ is used to specify the acceptance criteria of the user story. An acceptance criterion is used to ascertain when a particular user story can be marked as done and is normally used by the product owner to validate the same. The acceptance criteria also help the development team implement the business rules, functionality and will be the single point of reference for the Quality Assurance Team. The description field in JIRA issue creation provides space for the user to specify the acceptance criteria.   Gearset’s Jira Self-hosted (on-prem) and Jira Cloud integration lets you automatically post deployment updates to your tickets & keep up-to-date with the progress of your user stories. https://t.co/qvDlNK5LLr pic.twitter.com/yh8RmUL1Gm — Gearset (@GearsetHQ) 29 January 2018 Enabling discussion Another main aspect of writing requirements as user stories is to enable conversation about the feature among relevant stakeholders. This is known as the ‘Conversation’ component of user stories which is the 3rd C in the 3C’s.  Often user stories are accompanied with a process diagram, UI wireframe or a mockup, data dictionary etc. which can be added as attachments in JIRA or even be associated with the story as comments, wiki page links maintained in confluence. Conclusion Writing user stories is an easy method of maintaining requirements in a dynamic environment of an Agile project. JIRA, as explained above, provides a powerful and rich set of features which helps manage requirements in an efficient and convenient manner.    
Writing Effective User Stories in JIRA
Rumesh
Rated /5 based on 4 customer reviews
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

Writing Effective User Stories in JIRA

User stories are one of the main methods of communicating requirements to developers/development team in an Agile project. It is important for the individual tasked with documenting the requirements to be able to write effective and detailed enough user stories. The user stories are required to be comprehensive enough to enable the developer/development team to start analyzing, designing and developing the required functionality, feature or requirement stated in the user story. &nbsp; &nbsp; This article while intending to guide individuals on how to write effective user stories is also intended to advise on the best practices of creating user stories using JIRA as a requirements management tool for creating stories and tasks. What is a User Story? &nbsp; User stories are short, simple descriptions of a feature in the system under development told from the perspective of the person who desires this new capability. This person is normally a user of the system or even a customer who pays for the solution.&nbsp; User stories typically follow a simple template as below. As a &lt;type of user / user role&gt;, I must be able to &lt;some goal / feature&gt; so that I can &lt;some reason / benefit&gt;.&nbsp; User stories are often written on index cards or sticky notes and pasted on an information radiator or in other words a scrum board. This article is however on maintaining user stories using JIRA and on how the tool can be used to ensure regular conversation.&nbsp; Writing user stories on an index card is actually the &lsquo;Card&rsquo; part of the 3 C&rsquo;s in user stories. It is said that a user story should be long enough to fit into an index card and be detailed enough to arouse discussion. Writing user stories in JIRA A new user story in JIRA can be created by selecting the option to create a new issue of type &lsquo;Story&rsquo; as shown below.&nbsp; The user story in the format listed above can be written in the summary field of the new issue creation screen.&nbsp; User story definition should satisfy the INVEST criteria which implies that the user stories should be: Independent (of all other user stories and be able to exist on its own) Negotiable (not a specific contract for features but be able to be used to facilitate discussion among relevant stakeholders) Valuable (create some business value) Estimable (to a good approximation) Small (so as to fit within an iteration) Testable (in principle, even if there isn&rsquo;t a test for it yet) &nbsp; Trace your Customer Requirements to user stories in Agile through the integration with JIRA. https://t.co/esXyAJykZy pic.twitter.com/DZoa1tJrjL &mdash; Visure Solutions (@VisureSolutions) 21 November 2017 &nbsp; JIRA also provides the option to set priority of user stories which might have been done based on the MoSCoW criteria, due dates, assign the story to a team member of the project, allocate a story point/hour based effort estimation for the story, tag the user story to a component level feature or in other words &lsquo;Epic&rsquo; and be able to assign the story to a sprint during which the story is required to be implemented. Adding description to user stories The 2nd C of the 3 C&rsquo;s in user stories that is &lsquo;Confirmation&rsquo; is used to specify the acceptance criteria of the user story. An acceptance criterion is used to ascertain when a particular user story can be marked as done and is normally used by the product owner to validate the same. The acceptance criteria also help the development team implement the business rules, functionality and will be the single point of reference for the Quality Assurance Team. The description field in JIRA issue creation provides space for the user to specify the acceptance criteria. &nbsp; Gearset&rsquo;s Jira Self-hosted (on-prem) and Jira Cloud integration lets you automatically post deployment updates to your tickets &amp; keep up-to-date with the progress of your user stories. https://t.co/qvDlNK5LLr pic.twitter.com/yh8RmUL1Gm &mdash; Gearset (@GearsetHQ) 29 January 2018 Enabling discussion Another main aspect of writing requirements as user stories is to enable conversation about the feature among relevant stakeholders. This is known as the &lsquo;Conversation&rsquo; component of user stories which is the 3rd C in the 3C&rsquo;s.&nbsp; Often user stories are accompanied with a process diagram, UI wireframe or a mockup, data dictionary etc. which can be added as attachments in JIRA or even be associated with the story as comments, wiki page links maintained in confluence. Conclusion Writing user stories is an easy method of maintaining requirements in a dynamic environment of an Agile project. JIRA, as explained above, provides a powerful and rich set of features which helps manage requirements in an efficient and convenient manner. &nbsp; &nbsp;
Writing Effective User Stories in JIRA
Author Image
Rated /5 based on 4 customer reviews
Writing Effective User Stories in JIRA

Writing Effective User Stories in JIRA

Rumesh Wijetunge
User stories are one of the main methods of communicating requirements to developers/development team in an Agile project. It is important for the individual tasked with documenting the requirements t...
Continue reading

Project Contracts – A Vital Legal Binding

One of the key knowledge areas discussed in the Project Management Professional (PMP&reg;) certification is Procurements Management. As part of project procurements management a project manager is mainly expected to be able to initiate, execute and manage projects based on the project contracts. This article is an attempt to discuss about project contracts, to discuss the importance of such contracts and to give an introduction to types of contracts as a precursor to subsequent articles. Everything you ever wanted to know about contract digital project management. New blog post #dpm #digital #digitalagency #pmo https://t.co/WO7CAbwbHR pic.twitter.com/bWmeCfGbFr &mdash; ProjectManagementOD (@ProjectMOD) 22 December 2017 The PMBOK&reg; defines a contract as follows. &ldquo;Contract represents a mutually binding agreement that obligates the seller to provide the specified products, services or results, and obligates the buyer to provide the monetary or other valuable consideration in return. A contract can also be called an agreement, understanding, undertaking or a purchase order.&rdquo; (PMBOK&reg; 5.0) Any project involves two or more parties. One main party that is the buyer and the other the seller. In addition to these there can be other 3rd party elements that are not directly involved in the contract but are interested in or are impacted by the same. The contract between the buyer and the seller happens to protect the interests of the two parties entering into the agreement. The seller provides goods or services to the buyer for which the buyer compensates the seller monetarily or through other financial or non-financial means. &nbsp; A contract is a formal agreement between the two parties and it is a legal binding amongst the two entities. A formal contract must be in written format and can be used even in court of law in the case of either party failing to honour their commitment or in the case of an appeal against any misdeeds. Dishonouring contracts may actually lead to settlements even in court but should ideally be settled mutually among the disagreeing parties, most probably through a mediator called an &lsquo;arbitrator&rsquo;. Normally in large organizations contracts are managed by a separate contract manager or a procurements manager. The management of contracts are done in 2 separate ways namely; centralized contracting and decentralized contracting. In centralized contracting, one contract manager manages all the contract related matters for multiple projects. This requires expertise in contracting, standardization of contracting practices across the organization and more focused management of contracts. In decentralized contracting, separate contract managers are allocated to manage the procurements for individual projects. This results in full time management of contracts and the contract manager must report progress to the project manager. This results in more focused management of project contracts and with time creates specialized expertise in contracting. However, this may result in duplication of contracting expertise and less standardization of contracting practices across multiple projects in the company. #Passivehouse builder @AdamJCohen discusses the &quot;gold standard&quot; of Integrated Project Delivery contract typeshttps://t.co/rpk6GXV87W &mdash; Passive Buildings (@PassiveBldgsCan) 2 November 2017 &nbsp; There are three main types of contracts. They are Cost Reimbursable OR Cost Plus, Time and Material or Unit Price and Fixed Price or Lump Sum contracts. &nbsp;The applicability and use of these contract types based on the type of project, complexity and the parties involved may decide on variations based on the charges involved in order to ensure that the contract terms are mutually beneficial for the two parties. Hence, these contracts vary based on the cost, time and price.&nbsp; A cost plus or cost reimbursement contract is a contract in which the contractor is reimbursed or paid all the actual expenses they incur when carrying out the work. In addition to this they are also allowed to charge an extra fee allowing them to obtain a profit. For example a contractor taking up building a contract may claim resource costs as well as any miscellaneous expenses incurred for travel, food, purchases as well as charge an additional amount from the customer in order to make a profit from the tasks carried out. A fixed price contract on the other hand does not depend on the resources utilized or time expended. A fixed amount is agreed upon between the contractor and the customer where the amount is paid to the contractor even if the resources expended is lower or higher than the agreed upon amount. Time &amp; material contract is where the contracting party is paid only for the amount of time or resources spent. For example if there is a software development firm which assigns 4 resources for a project on a T&amp;M basis the company will be paid an hourly rate for each resource based on the amount of time they spend on tasks in the project.&nbsp; Each contract type has its own pros and cons for both the contracting and implementation party. For example a fixed price contract is suitable for an organization as they would know the amount due before hand and know that they won&rsquo;t end up paying extra if the triple project constraints are not met. Similarly, a time and material project may be suitable for both parties, as amount will be charged only based on the amount of work done in the project and for the time spent. Advantages and disadvantages of each contract type depend on the context. Thus, it is important for stakeholders involved in projects to negotiate on contracts wisely.
Project Contracts – A Vital Legal Binding
Author Image
Rated /5 based on 3 customer reviews
Project Contracts – A Vital Legal Binding

Project Contracts – A Vital Legal Binding

Rumesh Wijetunge
One of the key knowledge areas discussed in the Project Management Professional (PMP®) certification is Procurements Management. As part of project procurements management a project manager is mai...
Continue reading

The Business Case – A Key Artifact of A Project Managed As Per PRINCE2

One of the key deliverables in the process of initiating a project managed using the PRINCE2 methodology is to create the business case document. A project in PRINCE2 is defined as &lsquo;A management environment that is created for the purpose of delivering one or more business products according to a specified business case&rsquo;. What is a business case document? Why is it important to create one? What are the key decisions made using the business case document when initiating a project? How will the business case help in managing and controlling a project and in ensuring that the project continues to deliver business value? This article aims to address above questions. &nbsp; Why create a Business Case document? A business case is mainly used to document the justification for undertaking the project, based on the estimated cost of development and implementation against the risks and anticipated business benefits and savings to be gained. It is a justification for an investment based on the costs versus the anticipated business benefits of the solution option selected for implementation. &nbsp;The business case is a primary mechanism of project decision-making and is a means of assessing alternative and competing investment / solution options.&nbsp; When should you create the Business Case document? For organizations following PRINCE2, to get to the point of creating a business case document itself involves a big process. Requirement for projects arise from different sources. For example strategic level stakeholders may have strategic objectives that they wish to fulfill which may result in projects. Similarly tactical managers, functional managers and even operational staff may have problems that need to be resolved or business opportunities that they want to take advantage of which may result in projects. The context or the environment that they operate in and the stakeholders involved too may have an impact in creating requirements for new projects. A project mandate would first of all be generated once a business need such as above is identified. The scope inclusions and exclusions of the project should be identified and will help identify solution options to meet such requirements. The initial group of individuals would then be generating solution options to solve the identified problems or opportunities. For each solution option a detailed feasibility study should be done along the four main feasibility study dimensions of operational feasibility, technical feasibility, time feasibility and cost-benefit feasibility. This would help the team identify the advantages and disadvantages of each solution option and help select the most suitable solution option. This analysis must also include an initial assessment of the cost, potential timelines and the risks involved. Creating the Business Case and sections of the document The business case documents the justification for undertaking the project, based on the estimated cost of development and implementation against the risks and anticipated business benefits and savings to be gained. The content for the document is based on the analysis explained above. The sections of a properly formulated business case are as listed below. Executive Summary &ndash; Summary of the content of the business case document including details about the organization, business problem &nbsp;/ opportunity, key stakeholders, solution options evaluated and the solution option selected. Reasons for the project &ndash; Reasons as to why the project is needed including analysis of the current state, the future state and an identification of the gap. Solution options &ndash; The different solution options evaluated outlining the rejected solution options and detailing out the preferred solution option. Feasibility analysis &ndash; A summary of the feasibility analysis done on the identified solution options. Expected benefits for the selected solution option with explanations and assumptions. Expected disbenefits for the selected solution option with explanations. Summary of project costs taken from the project plan. If the project plan is not created yet it would be good to have an outline cost for the selected solution option. Investment appraisal &ndash; The organization may do an ROI, NPV, IRR analysis to ascertain the potential viability and benefits from the project. Risk analysis listing out a risk log with positive and negative risks along with risk mitigation strategies. Timescales &ndash; Outline execution plan that will be detailed out in the Project Initiation Document (PID). Continual assessment of project progress using the Business Case The business case document provides a blueprint based on which project progress can be monitored by the project manager and the project board. It provides a means for continuing to assess the viability of the project. In PRINCE2, the Project Board normally reviews the business case at the project initiation stage, end of each project stage, when any exceptions arise and at stage or project closure. The business case would be the main input to create the Project Initiation Document (PID) for the selected solution option. Some teams put a summary of the business case findings as a section in the PID document itself and use it to make an elevator pitch to the business sponsor and other senior executives of the project board. Once the project is approved, the project manager is assigned and he would create the project charter document with key inputs from the business case. The Project Manager and the Project Board will monitor the ongoing viability of the project against the business case. At the end of each stage or iteration the relevant stakeholders will sit together, evaluate the deliverables related to both the product and the process against the expected benefits identified in the business case to ascertain whether the business value set out to achieve is being met. Decisions to get the project back on track would thus be based on the baseline intentions defined in the business case. Finally, the business case is used to assess whether benefits are achieved when the project is delivered through a post implementation review.&nbsp; The business case is not a constant. It may change multiple times during the lifetime of the project. Evaluation at the end of each iteration or stage will help the project team and the project board realizes that changes are required in terms of objectives, expected business value, scope or even timelines. Hence, the initial business case may become invalid and thus be required to be updated with the consensus of the key stakeholders.&nbsp; The discussion above is just an introduction to the ocean of creating business case documents. Hope this will inspire you to further dive into this ocean.
The Business Case – A Key Artifact of A Project Managed As Per PRINCE2
Author Image
Rated /5 based on 20 customer reviews
The Business Case – A Key Artifact of A Project Managed As Per PRINCE2

The Business Case – A Key Artifact of A Project Managed As Per PRINCE2

Rumesh Wijetunge
One of the key deliverables in the process of initiating a project managed using the PRINCE2 methodology is to create the business case document. A project in PRINCE2 is defined as ‘A management...
Continue reading

Tips For An Effective Retrospective Meeting

The sprint retrospective in Agile is the scrum ceremony that allows team members to see how well the sprint went in terms of adopting and adapting a defined process. Even in change driven agile projects it is important to define a process that can be agreed and followed by all the team members in order to deliver value in a continuous manner without hindering progress. Thus, checking whether this process was really effective and whether it actually contributed to the effort of continuous delivery is an important activity for any agile team. &nbsp; The bottom of the pile However, the sprint retrospective is often given step-motherly treatment among all the scrum ceremonies. Retrospective meetings often happen at the end of the sprint or before commencing the subsequent sprint. Sometimes, the retrospective happens along with the sprint review that is carried out to evaluate the product or solution as to whether it meets the acceptance criteria. Teams often neglect the sprint retrospective or just quickly go through it just for the sake of holding a retrospective meeting. Purpose of the Retrospective? One major reason for ineffective retrospective meetings is the miscommunication or misunderstanding of the purpose of retrospective meetings. It is important that the Scrum Master informs the entire team about the purpose of the retrospective meeting. The primary reason for a retrospective meeting is to identify areas of improvement for the process being followed. Hence, the analysis is on the expected process, the actual process followed and an analysis of the gaps identified along with a set of ideas for improvement. &lt;iframe width=&quot;560&quot; height=&quot;315&quot; src=&quot;https://www.youtube.com/embed/EHwpxgZFc_k&quot; frameborder=&quot;0&quot; allow=&quot;autoplay; encrypted-media&quot; allowfullscreen&gt;&lt;/iframe&gt; Below are a few approaches commonly used to document findings from a retrospective meeting. The team has the freedom to define whatever approach works well for them. Working, Not working, Puzzling Start, Stop, Continue Good, Problematic, Significant What went well, What went wrong, What needs to change, Mad, Sad, Glad Liked, Learnt, Locked, Longed for&nbsp; Most team members complain that retrospective meetings are monotonous, non-value adding or boring and that they consider it as a waste of time. Below are some tips on how to make the retrospective current and engaging. &nbsp; Shared Responsibility&nbsp; Normally in agile projects, the Scrum Master who is the protector and coach for the process has the most interest in carrying out the retrospective meeting. But it is not a must that the Scrum Master needs to be the one organizing and facilitating these sessions. It is always good to hand over this responsibility to a team member and to challenge them to come up with innovative ideas to make the retrospective innovative and engaging.&nbsp; Retrospective meetings are normally presided by the Product Owner or client stakeholders as well. It may be them who are holding back or limiting project progress through their actions. In order to facilitate freedom of speech, a neutral facilitator can be assigned on a rotating basis and the scrum meeting can be carried out as a &lsquo;Round Robin&rsquo; or even a &lsquo;Pencil &amp; paper&rsquo; brainstorming session. Set the Context It is always important for the facilitator to set the stage for the meeting. The facilitator must define the purpose and ground rules for the meeting along with the expected outcome. Ice Breaker speeches, Motivational videos, Collaborative games etc. can be innovative ways to ease everyone into the meeting and to get them to share ideas without any inhibitions. It is also important to revisit findings from previous retrospective meetings in order to ascertain whether remedial action has been implemented properly in order to ensure that findings do not recur. Gamified Retrospectives&nbsp; One drawback at most of the retrospective meetings is the lack of participation. Limitations with culture, communication, as a result of respect or even through fear of punishment people refrain from contributing at retrospective meetings. Thus, the usual set of findings pop-up at each retrospective meeting.&nbsp; The facilitator must play a key role in running the meeting as a time boxed game where he can encourage participants to generate ideas, write them on sticky notes and post them on walls. Fish bowl meetings, Motorboat meetings etc are some more techniques to encourage participation. Identify enablers which makes the process work and any distractors which hinder the process. Once enough ideas are generated, the next step would be to generate insights, group them into themes and to assign possible action items. Generate Insights &amp; Action Items The facilitator may use affinity technique to group ideas to common themes or categories. Some categories may be communication, collaboration, leadership, &nbsp;trust, understanding of process etc. This will help the team grow on those ideas in order to generate actionable ideas. It is important to also look at the progress of action items from past sprints, and to analyze any ideas or action items that may be repeating. Repetitions may actually mean gaps that the team has not been able to successfully address and needs urgent attention. Value Everyone&rsquo;s Opinions Facilitator must ensure that the team values the inputs of everyone. No mud slinging, finger pointing or blame games should be tolerated. One way to increase collaboration is to stress on the positives and commend on accomplishments of team members. &nbsp; &nbsp;The Wrap Up One important aspect that the facilitator and the team miss out on is to wrap up retrospective sessions properly. The findings and action items from the meeting must become the motivators for the team on how they are going to perform during subsequent sprints. Thus, it is important to get the team to act upon findings from the sprint and to make necessary changes to the processes. So, let&rsquo;s make retrospectives work. Let&rsquo;s make them the catalyst for continuous improvement of agile teams. &nbsp;
Tips For An Effective Retrospective Meeting
Author Image
Rated /5 based on 20 customer reviews
Tips For An Effective Retrospective Meeting

Tips For An Effective Retrospective Meeting

Rumesh Wijetunge
The sprint retrospective in Agile is the scrum ceremony that allows team members to see how well the sprint went in terms of adopting and adapting a defined process. Even in change driven agile projec...
Continue reading

Project Quality Management: The Key Indicator of Project Success

The PMBOK&reg; defines quality as the degree to which a set of inherent characteristics fulfills requirements. &nbsp;A project is said to be meeting its quality expectations when all the project requirements agreed at the inception of the project are met, and thus the resulting product or service is usable for the relevant stakeholders.&nbsp; Quality is Subjective&nbsp; Quality for one individual will not be adequate for another. For example, the youth will consider a mobile phone as being of high quality based on its look and feel, brand name and its specification such as camera quality, memory capacity, screen resolution, ability to connect with other devices etc. and based on the support to run applications on the phone. However, for someone in the age group of 60 and above, the ability to take a phone call or send an SMS and whether this can be done without much hassle alone may define the quality of the mobile phone.&nbsp; To understand the quality requirements tailored to projects, it is necessary to have an exhaustive Quality Management training such as the Certified Manager of Quality Training. Quality has many faces The definition of quality depends on the context and the business domain. For a service-oriented organization such as a bank, a restaurant, an airline etc. quality of service is identified through the level of customer satisfaction. For a product such as a mobile phone, a vehicle, a computer etc. quality means conformance to product specifications and its fitness for use.&nbsp; In the context of healthcare sector, mission-critical military activities etc. quality is measured through precision and accuracy. Precision refers to the granularity of measurement and how fine the outcome can be measured. Accuracy simply put is the correctness of the output or being close to the desired value. &nbsp; Here are the four things #CIOs need to know about quality https://t.co/gRfqoTEUB7 #Qualitymanagement pic.twitter.com/KHMz5iC6RN &mdash; CIOReview (@cioreview) January 7, 2018 Quality is everybody&rsquo;s responsibility&nbsp; Quality in project management is two-fold. Project Quality and Product Quality. Project quality is to ensure that the project is executed in line with the triple constraints of time, cost, and scope. If the project is within the defined tolerance levels of these three dimensions, then we can say that the project is of high quality. Projects are carried out to develop a solution; i.e. product, service or a result. If this solution meets its specification or meets the needs of the stakeholders then it is said that the solution is of high quality. &nbsp; Meeting the quality expectations is not merely the responsibility of the project manager, but of everyone involved in the project. Achieving quality involves cost where it is the responsibility of everyone involved in the project to manage the same. Increased efforts and costs can increase the quality of output but a ceiling on this investment has to be fixed. Yes, it is the responsibility of the project manager to manage this ceiling value and to ensure optimal levels of quality within the project but he or she can only do this with the support of his team members. The optimal level of quality can be achieved when the incremental cost of achieving quality is equal to the incremental revenue from such quality improvements.&nbsp; &nbsp; What digital transformation means for the future of #qualitymanagement: https://t.co/0gyCaHsKtb &mdash; Sparta Systems (@SpartaSystems) January 17, 2018 Cost of Quality In order to achieve this, the project will have to incur some cost and this is known as Cost of Quality. This includes all costs incurred over the life of the product by investment in preventing non-conformance to requirements, appraising the product or service for conformance to requirements and failing to meet requirements or in other words rework. Thus, the cost of quality is of two main types- Cost of Conformance &ndash; This is the money spent during the project to avoid failures through prevention or appraisal. Prevention costs are costs incurred to prevent errors by the way of training, documentation, maintenance of equipment, quality control etc. Appraisal costs are incurred to assess the quality by the way of testing (quality assurance), inspections, etc. Cost of Non-Conformance &ndash; This involves the money spent during and after the project because of failures. Two main types of such costs are cost of internal failure and cost of external failures. Internal failure costs involve rework, scrap costs that are incurred before the solution is released. External failure costs are more critical where these are incurred to rectify damages of products failing once released to the customer. Such costs include liabilities, warranty, loss of business, damage to image etc. &nbsp; Quality Management is an important aspect of Project Management. PMI&reg; thus has given a central position to the same when defining the knowledge areas in the PMBOK&trade;. It is thus important for project managers and team members alike to understand the importance of quality and to better manage projects to achieve all expectations pertaining to quality. &nbsp;
Project Quality Management: The Key Indicator of Project Success
Author Image
Rated /5 based on 2 customer reviews
Project Quality Management: The Key Indicator of Project Success

Project Quality Management: The Key Indicator of Project Success

Rumesh Wijetunge
The PMBOK® defines quality as the degree to which a set of inherent characteristics fulfills requirements.  A project is said to be meeting its quality expectations when all the project requi...
Continue reading

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 &lsquo;Create&rsquo; option on JIRA opens up a pop-up window that allows the team member to create an issue as indicated in the image below.&nbsp; 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.&nbsp; Epics in traceability wth atlassina&nbsp;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.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; 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. &nbsp;
Best Practices When Using JIRA
Author Image
Rated /5 based on 20 customer reviews
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.&nbsp; 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&reg;) 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.&nbsp; 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.&nbsp; Clients too need to adapt to these changes by first being onboard to Agile contract types of Time &amp; Material models and be receptive for a continuous definition of requirements and ever-evolving solutions. &lsquo;We&rsquo; vs &lsquo;I&rsquo; One of the common problems which most of the teams have is with regards to &lsquo;groupthink&rsquo; and the &lsquo;dominator&rsquo;. 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.&nbsp; 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!! &nbsp;
Struggles of Becoming Agile
Author Image
Rated /5 based on 20 customer reviews
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&rsquo;s leadership ends up stressing over how to resource the project team.&nbsp; 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.&nbsp; 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&rsquo;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.&nbsp; The staff member though allocated to a project still reports to his or her functional manager. Thus, the staff member&rsquo;s performance is still tracked and taken note of, thus resulting in better performance evaluations and an uninterrupted progression in one&rsquo;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&hellip; 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&rsquo;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. &nbsp;
A critical analysis of ‘Functional’ Project Management Organizations
Author Image
Rated /5 based on 20 customer reviews
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. &nbsp;In some cases, the Business Analyst&rsquo;s involvement begins prior to the project inception in the pre-sales and feasibility stage and go beyond the project&rsquo;s end into the operations and maintenance phase.&nbsp; 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&reg; defines two major categories of artifacts. They are work products and deliverables. What is a work product? The BABOK&reg; defines a work product as:&nbsp; &ldquo;A work product is a document or collection of notes or diagrams used by the business analyst during the requirements development process.&rdquo; 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 &lsquo;bring forth or draw out&rsquo; requirements from stakeholders using various elicitation techniques. Though requirements available in documents or on existing legacy systems can be &lsquo;gathered&rsquo; 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.&nbsp; 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&reg; defines a deliverable as:&nbsp; 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. &nbsp;Business Analysis Deliverables are normally identified during the business analysis planning stage and get included in the project management plan as well.&nbsp; 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.&nbsp; 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. &nbsp;
Business Analysis Work Products and Deliverables
Author Image
Rated /5 based on 20 customer reviews
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&rsquo;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&reg; can be decoded as follows. What is a business? Let&rsquo;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. &nbsp; 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 &lsquo;MICRO&rsquo; or Internal Environment. MESSO environment consists of immediate inbound and outbound logistics service providers in the supply chain (which includes suppliers, supplier&rsquo;s suppliers, customers (wholesalers, retailers etc.) and their customers). &lsquo;MACRO&rsquo; 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?&nbsp; 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 &amp; 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&rsquo;s fortunes. For example investing in new technology, R&amp;D for new products etc can be such opportunities. Finally, What is Business Analysis? The BABOK&reg; version 3.0 defines Business Analysis as follows. Business Analysis is the practice of enabling change in an organizational context, by defining needs &amp; recommending solutions that deliver value to stakeholders.&nbsp; 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. &nbsp;
Core Business Components in Business Analysis
Author Image
Rated /5 based on 20 customer reviews
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

SUBSCRIBE TO OUR BLOG

Share Blog

View All Topics

Follow Us