Skip to main content

Tag: Business Analysis

How Do You Manage an Offsite Business Analyst?

Written by Emily McCreadie on . Posted in Articles. 1 Comment on How Do You Manage an Offsite Business Analyst?

Do you, as a manager, actually know what your employees are doing on a day by day basis on client site? Are you aware, until their performance appraisal, of what projects they are working on and what tools they’re using to get the job done?

I am in a situation faced by thousands of consultants around the globe. How do you fairly represent your day to day job to your manager? I either end up:

  • ‘Bigging myself up’
  • Talking my achievements down

And always…

  • Getting positive but mostly useless feedback from clients

Let’s address them one by one.

Having worked on one or more projects for months, a BA (should) know each and every one of them inside out. A BA (should) know all of the things that went right/wrong, hopefully produce a lessons learned report that you (should) be able to recite in your sleep. So when describing your role in this project of course you’re going to sound knowledgeable, efficient, and demonstrate a level of understanding that would make the Dalai Lama feel queasy.

But is what you achieved as impressive as it sounds?

At this point it’s down to the manager to delve further. They have most likely been a BA at some point in their career and should know how to make you squirm!

But this is a performance review, not an interrogation!

Of course it’s not… that is why it shouldn’t come to a performance appraisal for you to know what your employees are doing. Even if you’re based in a different county you should still be able to pick up the phone at least once a month. This not only helps employees ask that annoying question about timesheets, but also feel a bond to the ‘mother ship’ and discuss that Christmas Party (did you hear what Lisa did in the boardroom?!).

At the end of the day, there is no point in exaggerating. Your manager should have regular enough contact with both the consultant and the client in order to understand what is expected of both the project team and individual employees. The same should apply for ‘talking yourself down’… there is no place for modesty in a performance appraisal. Unless you don’t like pay rises of course…

What about feedback?

It’s so rare for your own colleagues/manager to provide honest feedback why should your client? If you’re not up to the job they can just send you back to the dogs bench.

Unless I ask for feedback on specific areas I would generally receive a paragraph saying that I turn up to work on time, I do everything that is expected of me and I have a great relationship with stakeholders. Oh, and I’m really good at organising people’s leaving presents…

Surely companies should have a template for feedback provided to clients to enable them to answer honestly and fairly about the consultant? Or is it up to the consultant to have enough common sense to do it themselves?

For each of the consultant’s project related SMART objectives there should be a measure which a client can comment on. The feedback can then be sent to the manager, the consultant or both.

How many requirements document did Lisa churn out in 2013? Who’s Lisa and what’s a requirements document? Oh dear Lisa, I think we need to talk…

This all boils back to the way that your company performance manages you and your fellow employees… I just hope for your sake you’re not your company’s version of Lisa.

Don’t forget to leave your comments below.

Business Rules – Seriously?

Written by Dan Tasker on . Posted in Articles. 1 Comment on Business Rules – Seriously?

As a consultant I see a variety of templates at different client sites for documenting requirements or use cases. Many of these include a section for recording business rules. Like many BAs I have a basic intuitive understanding of what a business rule is, but as I ‘know a guy’ I decided to catch up with the latest and greatest thinking in the business rules domain. I’m a firm believer in “it’s not what you know, it’s who you know.”

My ‘guy’ (a woman actually) is Keri Anderson Healy. She is the Executive Editor of the Business Rules Journal. She kindly shared with me her slides from a presentation she gave last November. While I can’t share the slides themselves, I can share what I consider the take-away points.

Point #1 – Under business jurisdiction”

Business rules are rules that the business enacts, and has the power to revise or discontinue. A business may be constrained by external factors such as the laws of nature or government regulations. These are considered rules, but not business rules (unless of course your business is governing (or you are Mother Nature)).

Point #2 – Detailed enough to produce a consistent result

A well-defined business rule should be sufficiently detailed and precise that any person expected to conform to the rule can apply it effectively and consistently in relevant circumstances.

In contrast to the level of detail needed for a well-defined business rule there is the related concept of Policy. Where a business has policies defined these can be sources of business rules. Keri’s example of a policy was “Safety is our first concern.” This policy acted as the basis for the example business rule “A hardhat must be worn on a construction site.”

The level of specificity between policy and business rule strikes me as somewhat similar to the relationship between high level requirements and detailed requirements.

Point #3 – Behaviour-related business rules

Business rules fall into one of two categories – behavioural and definitional. Behavioural business rules are intended to affect people’s conduct or actions. The idea is either to get a person to do something or prevent him/her from doing something. The hardhat example above is an example of a behavioural business rule worded to get people to do something (i.e. put on a hardhat).  Funnily enough the same rule could be worded from a preventing perspective – “No admittance to this site without a hardhat.” 

Advice is another concept in the world of business rules. Rather than restricting, advices are the business expressing explicitly what is permitted or not restricted. “No smoking, except in designated areas” is a behavioural business rule restricting people from smoking in undesignated areas belonging to the business. “Smoking permitted in this area” advises that people who want to smoke, can within the posted area.

Point #4 – Definitional business rules

Behavioural business rules are established by a business to get people to act in specific ways. Those rules ideally will be followed, but may not be by everyone, all of the time. Definitional business rules establish what is ‘true’ within the context of that business and remains true for the business as long as the rule stands.

The following examples are definitional business rules within the context of a car rental company:

Example 1 – A Driver is a person that has proof of a valid driver’s licence.

This rule ‘defines’ the concept driver within the context of this business. If this were a golfing business the term would likely have a very different definition. The trick with defining one term is that the other words/terms used in the definition need to be ones that are understandable to business people.

Example 2 – A rental agreement is not complete without identifying at least one driver.

This rule is about one specific status value of a rental agreement. Similarly to how behavioural business rules can be about preventing rather than doing, there can be definitional business rules about what is not true. That is the case here. The rule is stating that the status cannot have the value ‘complete’ under conditions defined in the rule.

Example 3 – A rental spanning seven or more days qualifies for weekly rates.

The third rule defines the conditions under which it is valid to utilise a particular set of rates. The specific rate value from within the set that applies cannot be determined from this one rule. There must be other rules defined that would work in conjunction with this one for identifying one specific rate that is applicable under those combined conditions.

As stated above, definitional business rules state what is or should be true within the context of this business (or what is not true within the context of the business). As the business operates there can be cases where what the rule states is not as it should be. For example, a person renting a car using a forged driver’s licence. While this violates the rule it does not change the definition of what a driver is for that business. Similarly, a rental agent might let a customer have a weekly rate on a rental of less than seven days, but that does not change the rule / definition of what it takes to qualify for that rate. Definitional business rules are what the business intends to be ‘always true’.

Point #5 – Context is everything (and language is a bitch)

We saw above that the term driver had one meaning in the context of car rental and another one in the context of golf. The good news is that the context of business rules is always the business or organisation managing its rules. The bad news is that one term does not equal one business rule. As seen in the examples ‘stating’ a business rule involves one or more sentences, those sentences containing a number of nouns and verbs in whatever language is being used (e.g. English). But that’s not all. Sentences, in addition to nouns and verbs utilise a number of qualifier words such as must, greater than, not and many more.

The objective of business rules is to get consistent behaviour or results. That involves consistent understanding of the terms used to express the rules, with sentences constructed in a way that the combination of terms is understandable to all involved.

Business rules – seriously?

Show of hands – who thought the three example business rules presented in Point #4 were ‘well-defined’ business rules? Prior to undertaking this article my hand would have been raised. But having ‘looked under the hood’ at what serious business rule people do, I know a lot more about how much I don’t know. Ideally the take away points from Keri’s presentation will have raised your awareness about business rules and the complexities of defining them well. For those of you that seek more on this subject there is a document Keri was involved with titled Semantics of Business Vocabulary and Business Rules (SBVR). It includes a meta-model of rule-related concepts and a case study showing many good examples of well-defined behavioural and definitional business rules. The document is downloadable at http://www.omg.org/spec/SBVR/1.0/PDF.

Where to from here? Personally I do most of my business analysis at the IT Project level. Serious business rule analysis is supposed to take place at the business level, independent of any IT projects or solutions. When necessary I will use those existing templates and do my best to represent business rules within the context of the project, incorporating what I learnt from Keri’s slides and numerous emails exchanged with her while drafting this article – thanks again Keri!

Don’t forget to leave your comments below.

Break Down the Business Analysis Boundary

Written by Kupe Kupersmith on . Posted in Articles.

kupe July23I seem to be getting inspiration from police departments lately. Stick with me, it is just a phase. Over the past six weeks, my city has been hit with a greater number of burglaries and robberies than normal. This rash of crime caused our small community to push our elected officials and police department for answers and accountability. To meet our needs for more information, the police chief agreed to meet the neighborhood at a monthly community meeting. The chief not only came with a few of his lead staff, but was also joined by representatives from two adjoining police departments. Since criminals do not see borders, the three police forces have come together to stop the crime in our area. 

What sparked my thought for a blog post was the willingness of the three police departments to share evidence and plan their approach to stopping the crime as one—not three separate—entities. If you know anything about police work in the United States, you know jurisdiction is typically a line that does not get crossed. Information is not shared freely between police departments. The attitude has historically been we will deal with our cases and you can deal with yours. If a crime was committed in our jurisdiction we want to catch them and convict them.

A similar attitude can be found on project teams. In many corporate environments individuals have the attitude of boundaries around one’s role. I’ll do my job, you do yours. The goal of individuals is doing their job well. If they do their job well then they think they are OK. If someone does not do their job well then it is their fault. The same is true from project team to project team.

What my local police and the other departments did is decide to focus on results and remove ego. The police departments don’t care who makes the arrest, just as long as the arrest is made. They shed a lifetime of a “this is how it has always been done” attitude and came up with an approach they think will work to address the goal. As a tax payer (stakeholder) I applaud my police department for looking for better ways to address our current issue. I think better of them for using this approach rather than one of isolation, even if they caught the criminal(s).

You and your team members have to do the same. Forget about titles and focus on the goal of the project. Your focus should not be about you. Do you think your stakeholders care if the business analysis was done well and the project failed? In the end all they care about is the project results taking care of their needs. They want you to do a good job, but more importantly, they want their issue resolved.

Most likely your teams are decided for you. You don’t get to pick and choose all the people you want to work with. The skills of the team members will include programming, business analysis, project management, quality assurance, database administration, subject matter expertise, etc. Your team has to come together and outline the tasks required to meet the goals of the initiative. Together the team needs to assign tasks based on expertise of each individual regardless of title. The team needs to be accountable for delivering a successful solution. In the large scheme of things, doing well on part of the project means nothing. A perfect example of this is if the business analyst does not have direct responsibility for project scope. If they just take the scope as is and don’t make sure there is a clear understanding of the business goal to be addressed, they are a bad team member. The fact that they did a great job with the functional analysis gets discounted if it was based on a bad scope. This may result in the true project needs not being met. A failed project and an individual failure.

This can’t happen without a culture shift and redefining how the team is rewarded. The days of collaboration are here and they are here to stay. Specialized work is still needed in some areas, but not all. Team members need to be rewarded for team results and behaviors that produce successful solutions. With my team I try to be clear on the goal of an initiative then leave it up to the team to determine the best approach. I reward open communication, collaboration, taking risks, the “I’ll take that on” attitude, failing fast, and owning up to mistakes. Smart, passionate team members truly collaborate, perform, and show results.

Don’t define yourself and others by their job descriptions. Focus on being a high performing team member and not just a high performing Business Analyst.

Communicate. Collaborate. Succeed.

Kupe

Don’t forget to leave your comments below.

It’s the End of the Business Analysis World as we Know it? Part 4

Written by Steve Blais on . Posted in Articles. 2 Comments on It’s the End of the Business Analysis World as we Know it? Part 4

Being the serialized story of Brian Allen and Ann Brady, business analysts, and their Adventures in the New Oder of Agile

Excerpted from the forthcoming book from John Wiley, The Agile Business Analyst due out the end of 2013

Blais Feature July2Chapter 4: Wherein the business analysts confront Dmitri and his curtains and provide a positive impact, and Verna phones in

Brian and Ann entered Dmitri’s office as he hung up from his phone call with Verna. He was still standing at attention behind his desk, his chair pushed back as though he had jumped to his feet involuntarily. He smiled at them and motioned them to seats in front of his mahogany desk while he pushed back the French cuffs of his shirt and sat down. Dmitri was slight of build and had longish blonde hair pulled back and parted in the middle.

Brian began the conversation. “Something is different in here than the last time I was in your office, Dmitri.”

“It’s curtains, Brian,” replied Dmitri. “I had them installed last week.” 

“Not bad. I guess you are doing well, then.” Brian paused and Ann picked up the slack.

“What are the new projects that you are undertaking, Dmitri? Do you have a prioritized list with some timeframes?”

“Of course.” He pointed to a white board on the side wall where there were a number of what appeared to be user stories written in different colored markers. In front of the white board was a small round table and several chairs, “This is where I have my product planning meetings and sometimes the teams gather round for their sprint planning sessions.” He said with pride and a trace of superiority as though to say, “and you are not invited or needed.”

Brian felt somewhat annoyed if not betrayed. He had worked with Dmitri in the past. . He and Dmitri had spent hours evaluating impacts of new functions and features that Dmitri and his staff wanted to implement. Brian’s analysis of Dmitri’s proposed initiatives usually uncovered unforeseen impacts in other departments in the organization. Brian then met with the impacted constituents to mitigate or ameliorate the impact, allowing Dmitri to go ahead with this initiative. And now Dmitri preferred a white board to Brian.

 

Dmitri rose from his desk and walked over to the white board. He read, “as a sales person I want to have access to product line information on my mobile device, so that I can provide that information to clients on an as needed basis.”

Brian realized that Dmitri was just showing off his new toy but he just couldn’t help himself. “Are there enough sales personnel who use their mobile devices during sales calls to warrant this feature? Or are we going to have to have all of the salespeople trained on how to use the new feature?”

“That is not my problem,” replied Dmitri.”I provide the facilities; it’s up to Sales Management to make the salespeople take advantage of it. That is a management issue, and is not part of the agile development of this product.” He said dismissively and quickly turned back to the white board. “Here’s another one.” He read a user story written in red with a date marked next to it, “as a customer, I want to earn points for my purchases, so I can exchange them for additional free goods.”

Ann chimed in, “what is that feature all about?”

“That is one we’re already working on,” Dmitri answered with growing enthusiasm. “We are building a reward program for frequent buyers to increase our repeat customer percentage. We’re going to award points, based on price and volume of purchase, which can be exchanged for gifts from a catalog. It will be like the airlines’ frequent flyer programs, except we’re not going to call it ‘frequent buyer program’. We’re working on the name of the program. We will put our higher-priced or slower moving products in the premium catalog. Everyone wins. It’s a great program. We’ve been working on the supporting software for three sprints and already have user screens for point exchanges to add to the website, the programs and the database that accumulates the points for each customer, the maintenance screens for the Points Database, and the program that calculates the value of the points and the exchange. We are also doing the marketing program in an agile way as well. We have three graphics artists developing the user interface. Got a couple of copy editors writing up the copy. Everyone’s turning things around in two-week iterations.” 

Dmitri’s excitement about the program was almost infectious, but both Brian and Ann saw warning flags.

Brian couldn’t stop himself again and asked: “you seem to be addressing the web-buying population. But what about the stores, the distribution channels and the retail outlets? Your user story does not limit to just web purchases. If you’re trying to attract more people to the web this might be a good program to do so, but it might enrage our distributors and retail outlets would perceive a loss in sales. If we lose our retail and distribution, we are doomed.”

Ann: “Did you consider that there will also be taxes to be paid on the gifts picked up with points? And if you order over the web, there is shipping. Will you charge the customer for that or absorb it?”

Brian: “Have you determined exactly who will be doing the maintenance and handling the customer support questions, of which there likely will be a lot? Corrine over in Customer Service has been complaining to me for a long time about how overworked her staff is. I doubt if they could take on this initiative at this time” 

Ann, “Did you get together with the accounting people, to determine how this is going to be carried as a liability? Basically, you’re creating an IOU to the purchasing customer for goods you’re going to deliver in the future. Accounting won’t let you start the program until that is all sorted out.”

Dmitri seemed somewhat deflated, or at least as deflated as a marketing person can be. “The team didn’t bring the issue of liability. They only addressed how the information would be transferred from the Points Accumulation Database to a general ledger interface.”

Ann interrupted: “That’s because they talk file layouts, not accounting principles.”

Dmitri looked at Brian. “We didn’t discuss anything but the web-based interface and how it was going to be created. The team should have thought about this and brought it up during the discussion of the user story.”

“It’s not their job, Dmitri,” said Brian. “They assume that you will take care of all the business impacts. They want to know what they need to do to implement the user story. If there are other impacts, they need to see other user stories. For example, have you considered how the points are going to be awarded at the cash registers of our stores and in the retail outlets that are selling our goods? And, how about inventory? The first time an item is taken out of inventory as an award the inventory will be out of balance. Since there will be no sales order to charge against and our current order entry system requires a sales order for inventory removal.”

Dmitri slumped noticeably and went back to his desk. He flopped into his chair. “I don’t understand. We never had to worry about such things before. We just come up with programs, see them through from a marketing and sales perspective, and then we do them. Who is taking care of these ancillary issues now?”

“This apparently is the New Order of Agile, Dmitri. What did Ken say to you about this?”

“I don’t think he did. He just said the product backlog is my responsibility. We have been using the user stories successfully for a number of iterations now. Are you telling me that when we finish all the work we are doing now that we still won’t be able to put the rewards program into operation?”

“I think, Dmitri, that you will run into a lot of production problems if you tried. Not to pat our own backs, but in the past Brian and I have handled the impacts and initiated projects for other departments to accommodate the marketing initiatives. We defined the capabilities that were necessary for your initiative to be successful, and you didn’t have to worry about it.”

“But there are no business analysts in agile. Ken and Vince say so. And I certainly don’t want to meet with all the other departments and business areas. They are all so retrograde.” 

“Yes,” warned Brian in a whisper. “But interruptions and impacts to operations come under Verna’s purview.” They observed a moment of silence staring down at the phone on the desk expecting it to light up with a call. The phone remained silent.

“Well,” Ann stood up and walked over to the whiteboard. She turned around with a wry smile on her face. “If the business analyst worked directly for you and was your emissary to the rest of the business he or she could identify the impacts and interfaces with the other business units and business processes. The business analyst could define what would be necessary to allow a successful implementation. The business analyst could bring back new user stories, or modified user stories that you, as product owner, could add to the product backlog in whatever priority order you desire. Then you can present the stories to the Development Team. So the business analysts aren’t really in agile, they’re not between you as product owner, and the developers.”

Brian chimed in, “not only that, but the business analyst assigned to your projects could meet with the business analysts who were still on non-agile projects and make sure that all impacts are resolved and all the projects are in synch. After all, Ken was quite adamant about the problems of still having waterfall projects in place with which his agile projects would have to interface. He wants the world to be agile and only agile, so he has no prescribed means of dealing with the non-agile teams.”

“I like it,” said Dmitri. “So you will assign at least one of your business analysts to work with me as impact analysts on all of these initiatives to make sure that all impacts to other business units and departments will be accounted for?”

“I think that can be arranged,” said Ann.

“Looks like we dodged another bullet,” breathed Brian as they walked toward the cafeteria for a cup of coffee after the meeting with Dmitri.

“Do you think we got Dmitri on our side?”

“What side is that?:

“In favor of business analysts. Realizing our value.”

“Not quite. He is using ‘business analysts’ as ‘impact analysts’. He clearly does not equate the two. He has been brainwashed by the New Order of Agile zealots.”

“Well, a business analyst by any other name is still a business analyst.”

“Let us keep that to ourselves, shall we?”

As they lined up amidst a crowd of caffeine lovers to get their coffee, Raj intercepted them, having to shout over the numerous mid-morning-break conversations around them. “Scott is looking for you. He seems desperate.”

“Wonder what that’s about?”

“Oh, and Ken is looking for you and he does not seem happy. Oh, and Verna’s secretary told me in the hall that Verna is also looking for you.” The cafeteria went silent.

Will the business analysts be able to remain business analysts in the New Order of Agile or will they have to change their names to protect the guilty or worse? What do Scott and Ken want now? Will Verna finally appear and put them out of their misery? Tune in next time when you will hear Scott say “there’s no crying in software development”, and see Brian sling his backpack over his shoulder.

Don’t forget to leave your comments below.

Applying Agile Principles to Requirement Analysis

Written by Ryan Hewitt on . Posted in Articles.

Background

The Agile methodology originated within the software development industry. Since its inception in 2001 – Agile has expanded beyond an initial developer-centric community – to being embraced by multi-discipline teams working across numerous industries.

The antecedent of Agile within IT was the Waterfall methodology. The Waterfall framework consisted of a series of sequential, discrete phases – with each phase conveniently mapped to a role/responsibly:

Analysis Phase -> Requirement Analysis (Business Analysts/Product Owners)
Design Phase -> UX (Designers/Usability Experts)
Development Phase -> Software Development (Developers)
Testing Phase -> QA (Manual Testers and Developers in Test)
Delivery Phase -> Release Management (Project Managers)

Due to the increasing popularity of Agile – requirement analysis has been encouraged to transition from being a stand-alone phase owned by BAs/POs – to become a project facet that can incorporate Agile principles.

In what ways can requirement analysis adopt Agile principles?

Collaborative requirement analysis

Prior to Agile – the practice of the development team being presented with an upfront, non-negotiable, detailed requirements document (BRD/functional specification etc) was common. With the advent of Agile – requirement analysis should no longer be restricted to the interaction between BAs/POs and the business – instead we should embrace collaborative requirement analysis:

A popular collaborative requirement technique is the “3 Amigos”. This process involves the developer, BA and QA discussing the requirement specification in a workshop. Each Amigo will offer a unique perspective – through discussions the Amigos will identify edge cases, undefined requirements, opportunities and potential reuse. The 3 Amigos technique can also reduce the risk of incomplete features being pushed into development by the product team – requirement specifications must be pulled into development when they have been reviewed and accepted by the 3 Amigos.

Collaborative requirement analysis facilitates a project-wide sense of ownership – and also communicates a common understanding of what features need to be built. Collaborative requirement analysis produces more robust specifications – and reduces the role-based silos that can exist on projects.

Detail as an emergent property

Agile artefacts such as technical spikes and development iterations mean that high-level requirements can be considered sufficient at project initiation. Low fidelity requirement assets (e.g. user stories /”back of the napkin” designs) should be employed on Agile projects:

Just-in-time requirements analysis (JITRA) has a concept that requirements should only be specified at the level of detail required for upcoming development. JITRA states that the further in advance of development requirements are defined – the more probable that requirements will become out of date, leading to rework and wasted effort.

Detail should emerge when it is required – which is typically towards the middle/end of the project lifecycle. Initial requirement analysis should be focussed on business justification and solution scope.

Embrace change

Specifications will evolve throughout the project lifecycle; all team members must acknowledge the benefit of responding to change. Adapting to changes in circumstances/urgency/understanding is crucial – requirement analysis should be considered an iterative rather than exhaustive process:

In terms of systems theory – project teams should be viewed as open systems. As the system will tend towards a steady state – change should be encouraged and communicated at an organisational level. Regular priority sessions, stakeholder workshops and competitor reviews should be used to mitigate resistance to change.

Incorporating feedback is crucial to the success of a project. Requirements are not unchangeable statements – they only reflect the current and expected situation, both of which are liable to change.

Necessary documentation

The adoption of Agile principles does not mean that requirements should not be documented. Requirement documentation is vital for developers, QA and the business stakeholders:

The principle of living documentation should be embraced. This means that all documentation needs to be accessible and up-to date. Business users, developers and QA should be able to request requirement changes.

Documentation is most valuable when it is understandable by all team members, available and responsive to change.

Lightweight documentation such as feature files and high level process maps summarise the output of the requirement analysis process. The Agile methodology encourages appropriate documentation – superfluous detail is wasted effort; Agile does not negate documentation.

Continuous process improvement

Requirement processes should not be viewed as immovable obstacles. Instead these processes should evolve and adapt to meet the needs of the project. Where a process or artefact ceases to produce the expected value –it should be reviewed and changed by a self-organising team:

Retrospectives are a popular technique for identifying improvement opportunities. Team members meet to discuss what the team needs start doing, stop doing, and continue doing. Regular (every 2/3 weeks) and actionable retrospectives provide an open forum for continuous process improvement.

Requirement analysis processes (to-be-analysis, process mapping, stakeholder workshops etc) can always be improved. A technique that is effective for one team – may not be effective for another – or at least may require several modifications.

Continuous delivery

The Agile methodology promotes product iterations and regular releases. In order to align with this ethos, requirement analysis must produce a constant output – a steady flow of requirements will avoid the “big bang” requirement delivery that characterised the Waterfall methodology:

Minimum Viable Product (MVP) provides the scope of requirement analysis. The MVP will be delivered in multiple iterations – requirement analysis must be constantly baselined against the MVP and ensure that there is a sufficient specification available for each delivery.

Shorter delivery timescales encourages more frequent requirement analysis output. Specifications should be aligned to the MVP – features need to be deliverable and contribute to the MVP vision.

Conclusion

Iterative, collaborative Agile development has replaced the sequential Waterfall development methodology. Prior to Agile – the product team could hand over a list of detailed requirements – which would then be used by developers to build the product. In order to align requirement analysis with Agile development practices – the following principles need to be applied: requirement collaboration, iterative specifications, embracing change, necessary documentation, continuous improvement and continuous delivery. By adopting these principles requirement analysis will transition into the Agile world, produce better specifications and ultimately lead to greater quality products.

Don’t forget to leave your comments below.