Contact Us
×

Tag: Agile course

Keeping High-Level Requirements High-Level

Posted on by Imarticus Learning

 

Stakeholders dislike repeated questions about their needs. They do not separate the details from the HLRs. But all is not lost. They do like being in on the sessions of project planning especially when they have a stakeholder role in it. Eliciting and organizing these HLRs to form a list of topics like the data exports, imports, UIs, automated functions, etc form the basis for further stakeholder discussions.

The following need is a good example: 

Ex: Each Customer record must be assigned a unique identifier.

While this is valid need it is not an HLR and should be noted but does not form an essential requirement of the project statement.

Let us explore how to keep those HLRs at a high level.

1. User story Vs the ‘Shall’ statement:

The ‘Shall’ statement is a formal single-sentence HLR. Agile uses a user story. The difference between the two is in the way the Agile or waterfall ecosystem manages them. HLRs are expected to be from the elicited SME stakeholder’s conversations and should be signed off by the stakeholders and used throughout the project’s life.

Agile uses user stories and a story backlog from the product owner. New stories can be written and a story has relative value on the story backlog with the highest-valued on top. Stories are to be refined by the PO’s contributions.

2. BI system capabilities:

The BI system supports

  • UIs 
  • Data Exporting/Importing 
  • Automated Functions
  • Reporting

An effective proper HLR should include the stakeholder need in the above areas and each represents a topic. The topic conversations discuss the detailed requirements of each phase and should involve SMEs who can support the process.

3. Reports with HLRs:

Reports are akin to a snapshot of the current data in the BI system. The HLR should contain the name of the project, the purpose of discussion, its audience, etc.

Details like the ones below should be left-out of HLR discussions and form a part of detail requirements:

  • Data sorting, grouping and selection criteria.
  • Triggering/scheduling reports.
  • Pagination and layouts.
  • Details of delivery.

This conversation with the SMEs is sufficient to make a report with HLRs on data.

4. Exporting and importing:

Data is in ‘machine-readable’ format and HLR discussions should establish answers to queries on

  1. Name of the process.
  2. Its data objectives.
  3. Whether the data expects real-time or background process responses to requests.
  4. The data needs of the person/system.
  5. The type of data involved as a primary entity.

This conversation with the SMEs is sufficient to make a report with HLRs on the exporting or importing of data.

These should be left out.

  • Criteria for data selection.
  • Sorting, summarization, file format, record layouts, and naming conventions.
  • Responses and real-time request parameters.
  • Value transformation, import data field-level validation, and error reporting.
  • Background job scheduling/triggering.
  • UI for exporting/importing.

5. User interfaces:

The HLRs should address these important UI topics.

  1. Activity or business process.
  2. User types.
  3. Primary entities in data.
  4. Any specific or selected instance.

User types are recognized as organizational roles. The answers to the above topic are to be used for the HLR statement. What is not to be included are

  • Data-fields for a list of one/all records.
  • Field layouts on a screen.
  • Invoked actions.
  • Navigation Options from record to other screens.

5. Automated HLRs: 

A BI system can be automated ‘programmed’ when deriving data is required of it. The following conditions should be met.

  • The data is available in the BI system.
  • The logic and rules of manually programming the function are described aptly by the SME/ Manager
  • The ‘translated’ description can be a computerized function.

The HLR statement should necessarily name the function as with a manual process, indicating the schedule for its performance and its triggers. Leave out from the discussions

  • The logic of the function
  • The record fields updated or added.
  • Triggering parameters details.

Conclusion:

Agile practices differentiate between details and requirements. It is vital that time is not spent unnecessarily in recording details instead of requirements. The four areas where one must keep certain factors in mind while recording HLRs are discussed to ensure that a high level is maintained in recording the HLRs.This is vital to Agile objectives and methodology.

If you are interested in learning more about Agile courses and HLRs, do a course at Imarticus Learning to bolster your practical Agile experiences and improve team productivity.

Three Modes of Business Analysis Consulting

Posted on by Imarticus Learning

 

A consultant for BA normally is a collaborator, expert, or an additional pair-of-hands when facing clients. The book by Process Impact’s Principal Consultant Karl Wiegers is about these three modes of interactions. Let us explore these to learn more.

1. The independent model:

The Expert:

The expert works with clients who have pain-areas and approach you to fix them through training personnel, process validation/assessment, or alter and review some process/ project documentation or deliverables. The expert can only help with the tools like the assessment of ineffective processes and practices, possible solutions to the root causes, the current position report or a roadmap to effectively reducing the causes of pain. Managers, practitioners, employees and the management need to work on culture changes and sustained improvement techniques to ease their own pain.

The collaborator of ideas:

The consultant is an expert collaborator of ideas supplying solutions and ideas that make processes and performance in them more efficient and productive. According to Karl Weiger’s personal experience out of ten generated ideas, two are bound to be ridiculous, another two not suitable to the culture and process, three could be obvious and tried already and only two or one novel, innovative and brilliant in the fit. Being client and technology appropriate is vital.

The Agile Coach:

The BA may also coach and become the expert consultant using his advice to study the current practices and help discover better ways of doing the tasks. On a bigger scale, they could be of use to maintain, monitor practice standards, and establish them from a

Centre of Excellence for business analysis. The BAs role could involve preparing training materials, developing methodologies, creating process and guidance documents, templates for project deliverables, and such.

Difficulties faced:

The NAH and NIH issues are general syndromes that creating resistance in organizations. By NIH-not invented here most expert-offered solutions get rejected because the people using it do not trust it. By NAH-not applicable here complaints clients disapprove solutions citing they wouldn’t work in their environment since they were different. The BA expert consultant and coach cannot implement their solutions and rarely get any feedback regarding the outcomes. This means change management is crucial to organizations who hire such experts to provide solutions which cannot work in isolation.

2. A many-handed mode:

Often the extra pair-of-hands mode has many benefits where the domain of the consultant is exploited since the company may lack time and staff resources though they can perform the task themselves. The client is allowed to independently assess deliverables with the consultant working on his own.

Ex: Hiring experienced BAs on a fixed-term contract basis for specific developments in a software project.

The consultant here performs the regular BA tasks like eliciting requirements, identifying users, writing specifications, and so on until the on-site project work is completed. Often deliverables are iterated and worked till the final product is acceptable. At times you may do the novel and innovative task. In such cases, a vision statement is absolutely mandated covering the following assessment parameters since the outcomes are fuzzy.

For whom? (targeted client)

For Who? (statement of opportunity and specific needs)

Is a? (Deliverable type)

That? (Key takeaways)

Unlike? (current process)

This deliverable? (The new deliverable differentiators) 

3. The side-by-side collaborator:

Collaboration is the key parameter in this mode where the consultant needs to work for side-by-side the client organization’s staff in creating deliverables, identifying solutions, making decisions and setting priorities. It could be an extended off-site engagement that is collaborative or in the independent pair-of-hands-mode of operation. It includes reviews of the governance process architecturally, making environment peer reviews, working on reviews and product objectives, developing e-learning presentations, drawing up review processes and training of staff, recording e-learning training courseware scripts and such.

Concluding notes:

It is always best to use the three consulting modes depending on the engagement type and the specific project needs. There will be times when as an expert you may not agree with the mode selected and that’s where one will have to keep the client’s best interests in mind no matter your role. Often you will function as all three-The consultant, the expert and the collaborator of ideas.

Want to learn more about Agile courses? Do a course at the Imarticus Learning Academy where careers are born and honed.

Retrospectives Make Better Product Outcomes

Posted on by Imarticus Learning

Most product managers and coaches struggle with frustrating outcomes. The answer to such a situation lies in the retrospectives. The Retrospectives-tool is an essential of the PMs toolkit and relies on learning, transparency and exploring curiosity in a safe environment. The product retrospectives can transform product processes, improve products, and offers an opportunity for continued learning through the iterative product development life-cycle.

Why Retrospectives?

The retrospective generates actions based on consensus and produces new information unlike the regular meets reviewing past performance, data and actions.
It is a based-in-reality change and action process which can be undertaken to occur at regular intervals. For example the quarterly review of road-maps, the finish of a sprint iteration, after a release, sales /client meeting, product launch or the hypothesis-testing. The retrospective reviews what, how and why in terms of reviewing over a fixed timeframe the desired outcome or event and comprises the entire product development community of stakeholders, customers, product and development teams.
The accruing benefits:
The retrospective is beneficial when it is able to: 

  • Use and gather community collective-wisdom.
  • Be neutral and non-judgmental about the truth.
  • Find areas for improvement and appreciation.
  • Generate beneficial product insights.
  • Try, change and make commitments to improvement actions.

The main benefits accrue when retrospectives are used for: 
·         Active Engagement.
·         Go beyond the process.
·         Use product data to make better product decisions.
Let us explore how retros help under each head.
Active engagement:
Retrospectives are important Scrum events for the teams in product development. However, the PD Managers avoid shoddily run meets on product quality instead of addressing the issues and making situations better. They are also useful in mutual learning and resolving key issues like strained team member relationships.
Transparency, a safe environment, and open communications are key in the retros. Product leadership starts with discussing in a neutral non-judgemental environment even undiscussables. The skilled facilitator can then help transition the team to the high-performance zone.

Go beyond the process:

Most times the Retrospectives are useful in development processes and go beyond product releases and sprint iterations. Retrospectives are event-based learning from events like the product launch, hypothesis test, product/customer research, roadmap-outcomes, and customer conferences. Your leverage depends on the events linked to your product, engaging the right people and post-event retros to learn from.

Use product data to make better product decisions:

Typically any retrospective involves the data gathering, culling of insights, and product-data focus for making good business decisions.

The Retrospective structure:

A structure has a series of activities like: 

  1. Readying the stage: Here one collects data required, starts the session with stakeholders, defines parameters for retro success, and creates retro safety.
  2. Using past data: Data here is used to recreate and tell the story using shared resources of quantitative and qualitative data.
  3. Draw present insights: This phase reflect on feelings and facts, interprets data accordingly, looks and understands the whole scenario while answering the top five retro-questions.
  4. Make future decisions: Here one decides the actions for implementation and decides what and when to change.
  5. Retro Closure: The whole process is reviewed for future use and improvements.

In retros, data is both quantitative (like coding, tech debts, quality, defects, etc) and qualitative (like happiness, reviews, reactions, etc). It also includes metrics of the HEART (like customer happiness, engagement, outcomes, adoption, task success, retention, etc). Factors like revenue, loss/win results, costing results over a time-period, metrics of marketing campaigns, test findings, hypothesis testing, and conversion rates are also part of it.

Retrospectives help to learn:

Retrospectives can enable learning when such learning is reinforced and is essential for self-direction, immediacy, and relevance. By Immediacy, one means you apply your learning immediately, by relevance one means it applies aptly to our situations,  and self-direction implies taking control of retrospection and make learning-based changes. Retrospectives hence should be mindful of everyone’s involvement in things that need change and the achievement of change itself.

Conclusion:

Retrospectives go beyond the obvious thinking. To practically use and reap better retrospective-based outcomes, the product leaders have to determine when to use, who can best facilitate, learn all about the timing, duration, etc, and possess safety from a psychological perspective.
In conclusion, ask yourself if using retrospectives and better productivity interests you. Do an Agile course at Imarticus Learning to further your career today.