Tuesday, 21 January 2014 08:03

What is an AGILE Business Analyst?

Written by
Rate this item
(33 votes)

Agile-newThere is a lot of talk among business analysts nowadays about something called an agile business analyst. This appellation is generally applied to business analysts who work in an agile software development environment. This is a topic of discussion among business analysts throughout the industry. Courses are being written and delivered about how to be an “agile business analyst”. There is a discussion group on LinkedIn, with the title “Agile Business Analyst”. One thread on that discussion group was started by Leslie Monday, August 29, 2011, titled “What Is An Agile Business Analyst” and it is still going strong. There are at least a dozen other threads in other business analysis oriented discussion groups on LinkedIn, attempting to answer the same question, and I’m sure there are similar discussions being carried on in other communities around the Internet, and most likely in local IIBA and other business analyst organization meetings.

In some cases the discussions have a certain desperation to them because the agile community itself has in the past, eliminated the business analyst role from the agile software development process. The anti-business business analyst vitriol has been quite strong over the years. The claim has been that the developers can do their own business analysis and an extra person in the position of business analyst simply gets in the way.

In these discussions there are those, myself included, who claim that a business analyst is, and really always has been agile. (A discussion started by Louise McDonnell that lasted several months challenged discussion members to come up with a clear differentiation between a business analyst and an “agile” business analyst.) The profession of analyzing the business requires flexibility, responsiveness, creativity, innovative thinking, acceptance of change, and a dependence on individuals and interactions. Such qualities are desired, if not required, regardless of whether the business analyst is involved with agile software development, traditional software development, or no software development at all.

So are agile business analysts “agile” because they work on an agile software development team? And if so, does that imply that those not working on an agile software development team are not agile? I contend that in business analysis, agility is a mindset having nothing to do with the framework in which the practitioner of business analysis works. In other words, an agile business analyst is agile whether he works on a scrum team, any other agile team, or no agile team.

Let me illustrate my point by differentiating between a business analyst working on an agile team, or a developer playing the role of the business analyst, on an agile team, and an agile business analyst. Before the agilists start screaming, I am not suggesting that this is a binary or exclusive differentiation. In the annals of agile, there is a constant reference to the difference between “doing agile” and “being agile”. I am trying to demonstrate the difference between “doing agile” and “being agile” as it relates to the business analyst.

We can look at an agile business analyst manifesto of sorts to describe what an AGILE BA is. You may find that the tenets of this “manifesto” apply to you even if you are not associated with anything remotely resembling agile software development. If so then you can call yourself agile for no other reason than the acronym associated with AGILE BA.

The characteristics of an AGILE Business Analyst


Clearly everyone associated with agile must be adaptable, since that is the essence of agility, according to the manifesto and those who promote it. However, the adaptability inherent in the agile software development approaches is focused on the flexibility required is a natural part of software development. The AGILE BA is not solely focused on software development or defining requirements for development teams. The AGILE BA defines improvements to business processes, assists decision-makers in gathering information to make decisions, helps quality assurance test solutions and products, designs user interfaces and even steps in as a product owner, scrum master, or project manager as the occasion calls for. The AGILE BA may define a set of requirements as a standalone document to outline what must be done by the organization to move to new facilities and then prepare the user stories in a just in time approach for an agile development team. The AGILE BA is not committed or bound by any specific process (software development or other). The AGILE BA is committed to solving business problems wherever they occur in the business however they may be solved. Therefore, the AGILE BA must be able to adapt to the business process, the software development process, or even a lack of process, and to any and all management directives, and not be focused on a single process or framework.

Goal orientation

The AGILE BA’s goal is to add value to the organization by solving business problems. While the developers are focusing on producing new pieces of working software every two weeks, the AGILE BA has a focus on the overall problem that will be solved when the entire project is completed. The AGILE BA is also the weathervane indicating when a project has outlived its usefulness and is becoming a zombie project. The AGILE BA, always having the goal or the solution in front of her, is able to determine whether the project is still on track, the problem can be solved, or the problem has already been solved. This goal orientation is the result of the AGILE BA’s system thinking capabilities and the business analyst’s ability to see the big picture in addition to the detailed tasks necessary to complete the next Sprint.


While the solution development team is focusing on completing the items on the backlog in a reactionary mode to be sure that software is developed every two weeks, the AGILE BA is looking for new approaches to solving the business problem and improvements to the business processes in which the problem exists. The solution development team must follow the dictates of the product owner as reflected by the prioritized product backlog. The AGILE BA challenges the business manager, sponsor, problem owner and users to define the real business problem behind the expressed “needs” to ensure that the solution team is solving the right problem, and not providing the right solution to the wrong problem. Innovation requires a modicum of critical thinking that may generate conflict and change, moving people out of comfort zones, and taking risks. Such risks are not commonly undertaken when the driving force is producing releasable software every two weeks and the whole idea of the fixed time box approach to agile software development is to create a comfortable rhythm for the development team to produce software. Breaking out of this comfort zone is not a desirable activity.


The AGILE BA is a leader providing solutions to business problems and continuous improvement to the organization. This leadership factor is not achieved through authority, but through influence and through facilitation and communication. A recent book edited by Penny Pullan, titled “Business Analysis And Leadership: Influencing Change”, written for “all who practice business analysis, whatever their job title.” Suggests that “business analyst lead through their work with stakeholders as they build understanding of what’s needed and look to the future”. The leadership of the business analyst on the agile team is usually focused on the team and the project, and the emphasis in agile approaches is on teamwork rather than individual leadership. To again quote from Penny Pullan: “while many business analysts see no need to look beyond their immediate project, outstanding ones will always have one eye on the organization they work within. They realize that, in order to make change stick, they need to understand and engage widely across their whole organization. This requires an understanding of the entire system, the ability to deal with power and politics, skills and working across boundaries of culture, and an understanding of both strategy and commercial realities.” And this defines the AGILE BA.


Throughout all the AGILE BA dealings with the business sponsor, customers, process worker’s, users, solution team, technical personnel and upper level management, the AGILE BA exhibits empathy and understanding and provides an intermediary who is a mediator, a calming center in the midst of the storm of controversy and confrontation that usually accompanies organizational change. A certain amount of empathy is needed on an agile team in order for it to function as a high-performing team. That empathy does not have to extend much beyond the team since, as defined by the agile frameworks, there is only one business person to talk to who represents the entire business organization. The AGILE BA is thinking relationship across organizational boundaries, and indeed outside the organization, empathizing with customers, both internal and external, which includes a wide range of personalities and attitudes.

Business orientation

Let’s face it, the agile software development team is focused on the technological issues of producing working software every two weeks. Granted, this working software must be oriented toward the business because it must produce value to the business, but many agile teams depend on the Product Owner or similar role to provide the business justification so they can focus on the production of software. The AGILE BA is unashamedly business oriented, thinking continuously about what can be done to improve the business, and the business processes which drive the business. The AGILE BA is thinking about what the business needs to do to solve the business problems in addition to what the solution team needs to do. The AGILE BA is as comfortable talking to senior executives about business matters, the marketplace and competition, as to the development team about user stories.


In a timebox driven, delivery focused agile process, the general guideline is to not plan more than one or two iterations ahead. As Jim Highsmith advises,” The agile approach assumes that the project plan is fundamentally irresolvable past a very simple approximation. There is no amount of information that will provide the resolution to the project issues beyond that point”. And that point is generally two - four weeks and within the somewhat narrow focus of the project itself: the system and the features or functions being developed. The AGILE BA is completely familiar with the problem domain, the business area in which the problem exists and is able to anticipate positive and negative impacts to other areas of the organization. However, the solution should be the best for the whole organization, and not just a particular business area. Therefore the AGILE BA has to retain enough independence to evaluate potential solutions based on the overall impact to the organization rather than the influence of the particular business area and its managers. Solving a business problem solely for the business unit might have immediate benefits; solving a business problem from the perspective of the whole organization brings much more lasting value.

So there you have it, a clever acronym to distinguish what an agile BA is. And, as mentioned earlier, to many business analysts following the tenets stated above, the words “AGILE BA” could be replaced by “business analyst” because the tenets define the job of analyzing the business, or being a business analyst, whether agile or not.

Don`t forget to leave your comments below.


Pullan, Penny and Archer, James, “Business Analysis and Leadership: Influencing Change”, Kogan-Page Limited, 2013
Highsmith, James, “Agile Software Development Ecosystems”, Addison-Wesley Publishers, 2002

Read 114126 times
Steve Blais

Steve Blais, PMP, has over 43 years’ experience in business analysis, project management, and software development.  He provides consulting services to companies developing business analysis processes. He is on the committee for the IIBA’s BABOK Guide 3.0. He is the author of Business Analysis: Best Practices for Success.


+5 # Jon 2014-01-21 13:36
The only real difference in being an Agile BA is one of method -- using a Lean Design approach to documentation and working within an agile environment. This takes adaptation and calling yourself an Agile BA implies that you have successfully adapted to the Agile environment - that you have experience (hopefully successful) in working within an Agile team.
Another item is that in the Agile projects I have (and am) working on I assume the part of the Product Owner. As a SCRUM certified Product Owner and having a dozen or so Agile projects under my belt, I feel comfortable calling myself an Agile BA -- that's an extension of, not a deviation from BA practice.
Reply | Reply with quote | Quote
+2 # steve 2014-01-22 06:19
I agree with you, Jon. I think that all business analysts should instinctively adhere to the lean principles in their own work and in analyzing the business processes that they are working on.
I don't really think there is such a thing as an "agile BA" as distinguished from any other "BA".
The business analyst is a role (one who performs business analysis) and can be performed by anyone regardless of position or title. 'Agile" is how we perform that role. I am suggesting that all business analysts seek to make their "how" more lean and more agile, in other words, more flexible and responsive to the organization's business problems.
I agree with you that 'agile' is not a deviation from the BA practice, but I am not sure it's an extension. Becoming more agile is perhaps part of the journey we business analysts take, and have been taking for years. We just have a name for it now.
My question is whether you feel you are playing the role of business analyst while performing the position of product owner?
Reply | Reply with quote | Quote
+13 # Tara 2014-01-21 14:09
I find the biggest difference between being an Agile BA and a BA working in waterfall is the scope of the requirements you create. Before I'd work on the requirements for the whole system and get sign off on the whole thing. Now that I'm working on a Scrum Team (usually as PO), I get the Epics for scope before the project starts, but then everything's explored in the rhythm of the 2-week sprints. I may take an epic and break it down into 5 or more stories, but I'm only getting detailed requirements for the next 2 or 3 (enough for a sprint of work from my small team). It's actually rather challenging to be thinking small, but also thinking about the whole process or even organization. Sometimes it can be easy to get lost in the immediate and forget about the big picture. That's a fight you have to figure out how to win with the correct balance.
Reply | Reply with quote | Quote
+2 # steve 2014-01-22 06:35
Good description of a BA working in an agile approach, but were you performing the role of business analyst or of product owner (regardless of your position title)?
Are you analyzing the business to produce those epics or are they being presented to you to decompose into stories or backlog items?
One of the things I have noticed about the Scrum teams I am working with is the problem you mention of loss of perspective. The product owners and teams get so wrapped up in velocity and bi-weekly delivery that they lose sight of the overall business problem they set out to solve. There is no one on the teams playing the role of business analyst who can step away from the code, evaluate the progress against the original business problem, and help keep the product owner and team on track.
A couple of questions, if you don't mind: you mention that you get 'detailed requirements for the next 2 or 3" sprints. Are you developing the detailed requirements? Are they in the form of user stories given to you by someone in the business? Are you writing the stories? Are you and the team together breaking the epics into stories and requirements?
In your role as product owner, do you get involved with the team when they break the requirements or stories into tasks and do the estimating for the next sprint?
Reply | Reply with quote | Quote
+3 # Leslie MUNDAY 2014-01-21 14:59
Steve, I think that I have expressed similar opinions on linkedin - maybe even under the thread that you referenced from Leslie MUNDAY ;-)

When I moved from SA/SD type approach to an OOA/D approach, I believe that I became a More Agile BA.

When I adopted use cases into my approach to BA, I believe that I became More Agile.

By organizing my use cases into fragments that may be assigned to 2 week sprints, I think that I have become an Agile BA.

All those other things that a BA does like, looking at the BIG picture, maintaining a record of the system, looking outside the immediate needs of the project; have not changed. The switch to Agile BA, has less than 10% impact on my role. 90% of that work, I was already doing on Waterfall projects.

So yes, for the most part the BA has always been agile.
Reply | Reply with quote | Quote
-2 # steve 2014-01-22 06:09
Thanks. Leslie.
I thought of you while writing this piece.
Reply | Reply with quote | Quote
0 # Katherine 2014-10-20 09:52
Could I have a link to the linkedin discussion?
Reply | Reply with quote | Quote
+1 # steve 2015-12-10 20:02
Katherine, there was a linkedin group called Agile Business Analysis. The thread which went on forever should still be in the archives
Reply | Reply with quote | Quote
-1 # Bill R 2014-01-21 15:41
Yikes Steve - where are you working or seeing places that "eliminated the business analyst role from the agile software development process?" I'm glad I haven't ended up there (and hope I never do!), the only possible exception being a very small shop where the resources simply don't exist to have a separate, full-time BA.

Anyway, no offense, but it seems to me that you have confused the common, non-IT definition of the word "agile" or "agility" (i.e. what you'd find in a dictionary) with being "agile" in terms of the Agile method, which does not mean simply to be "agile" in a general sense of the word. Agile is starkly different from the waterfall methodology in various ways, so BAs will generally (if not usually) work differently within them. Tara gave one clear example above. (PS: where's the "clever acronym?" AGILE is not an acronym)

That all said, thanks for the references to agile vs non-agile BAs on linked in; I'll have to go check them out, as this is an interesting topic.
Reply | Reply with quote | Quote
+3 # steve 2014-01-22 06:08
Yes, Bill, places do 'eliminate the business analyst", as a position, not as a practice. Scrum defines only three roles, none of which is business analyst. The concept is that in Agile, the team does not need an intermediary to talk to the business; the team talks to the business directly through the Product Owner or the On Site Customer. The team of developers does its own business analysis. And as a result, I have seven Scrum teams (teams of 7 - 12 players all working on the same overall project) at one client with nary a business analysts in sight.
My intention is to point out that "Agile" is not a set of practices, or prescribed approaches, but a mindset. A business analyst, or anyone, can march to the Manifesto and perform to the principles in any environment on any SDLC. One can be "Agile" without being involved in software development. (I set up Scrum for a marketing department back in 2012 - no software development at all).
I was trying to be "clever" in turning 'agile' into an acronym. It is more fun than just listing the qualities of an agile mindset for a BA.
My purpose is to reduce the fear that quite a few business analysts have expressed that there is no place for the role or position of business analyst in an Agile World.
Reply | Reply with quote | Quote
-1 # Jay 2016-03-16 01:04
Hi Steve, I completely agree with you . I am Senior Business Analyst and all the projects that I have worked has followed the Waterfall methodology. Currently, I have moved to another country and when i am looking for opportunities I can see lot of job positions titled Agile Business Analyst. Unfortunately, there is strict rejection for a Business Analyst who comes from a waterfall back ground which I feel is quite unfair. As you said Business Analysts has always been AGILE and always will be. Moving to an agile environment will be a cake walk for any Business Analyst who is passionate about his profession.
Reply | Reply with quote | Quote
0 # BIll R 2014-01-24 12:47
Steve, thx for the reply. I think people's fears of Agile/Scrum somehow squeezing BAs out is unfounded, so I'm glad you're trying to address that fear. We certainly do have our place and the need for us remains. In fact, just because some places don't have BAs and Scrum doesn't list a BA as an "official Scrum position" doesn't mean they aren't part of the team. I've worked on rather large, complex projects using Agile/Scrum and you better believe we had BAs. Fortunately for me. :)
Reply | Reply with quote | Quote
+2 # AllysonDiva 2015-04-27 13:59
I think another part of the problem is that a true Agile shop does not prize the BA role and there is no clear career path anymore for shops with Agile. You're condemned to technical piecework
Reply | Reply with quote | Quote
-2 # Mikael 2015-05-02 06:46
Quoting AllysonDiva:
You're condemned to technical piecework

I sometimes get comments from BAs that they are reduced to document the solutions already coded by developers. I'm unsure why they ended up at that point. In my projects the user stories and scenarios I describe dictates what the team develops. I stay away from the technical details. In my days as a developer the only career path was to be an architect.
Reply | Reply with quote | Quote
+2 # Brian L 2014-01-27 07:07
Good article Steve.
I couldn't agree more with the sentiments expressed in your article.
Typically I've found the BA role is being pigeon holed into that of a Scrum Master or Product Owner on Agile projects. And while there may be situations which dictate this approach, the emphasis for a BA must be on Business Orientation, where we can influence and guide Product owners, Scrum Masters, Developers and Test Analysts, by
- understanding processes and procedures
- appreciating the impact of change to the business area
- considering process definition / change in line with the Requirements / User Stories being developed in a Sprint
In regard to having oversight of the purpose and objectives of a Agile development, my experiences suggest the BA role helps for clarity of vision in Agile. Typically this will involve a period of discovery with the Product Owner, leading to a definition of the vision and high level objectives. And with the vision subsequently being broken down into High level vision components, which may the be considered as Epics and User Stories in the Agile sense.
The BA will also have an understanding of User Stories that must be delivered together to ensure the business receive functional software that provides a start point to end point coverage within a process for the business.

The BA role is and needs to be one that adapts and changes, with a core emphasis on Business understanding.
Reply | Reply with quote | Quote
+1 # steve 2014-01-29 06:29
Thanks for the comments, Brian. Well said.
Fortunately many agile teams are discovering the value of having a business analyst associated with the team whether on the team or not, and not in the role of either Product Owner or Scrum Master. That is not to say that some business analysts might find a higher calling in doing one or the other of those roles. In some of the newer flavors of Agile such as DAD and SAFe the role of business analyst (or similar role) is called out specifically. Business analysis is not going away. Business analysis was here long before computers were thought of, and will be around as long as business is around.
Reply | Reply with quote | Quote
-1 # AllysonDiva 2015-04-27 14:01
And one more thing which I think underlies a lot of why so many BAs hate Agile. In Agile Scrum, you're just "helping" and in non-Agile shops you are really more involved in leading
Reply | Reply with quote | Quote
+1 # Kevin Venning 2014-01-28 18:21
All this confirms that the term or description Business Analysts needs to move on as well .... we're Business Adaptors !?
Reply | Reply with quote | Quote
+1 # steve 2014-01-29 06:22
Kevin, I love the term Business Adapter. It conjures up all sorts of practices and change activities.
Reply | Reply with quote | Quote
0 # Anthony Horner 2014-03-25 16:52
Hi Steve,

Loved the article. However as a freelance BA I don't see the need for an "agile BA". There seems a lot of overlap between the agile roles (principally PM, PO & Scrum master) and the space formerly occupied by the BA. Maybe this agile BA role is a way to redefine ourselves so we are not left out of a job?

The agile tenets (iteration, collaboration, etc.) as applied to the waterfall BA role seem to me like basic good practice (nothing new here) but for those agile SW dev projects the BA seems like an extra cog.

Unfortunately the world is not so simple, there are projects that shouldn't be done in agile (e.g. with 3rd party dev teams in different time-zones) and POC mobile app pilots done in waterfall. Add to this the feeling of many hiring managers that they didn't want to fall behind when recruiting staff and the agile BA role was born.

In the end, be it agile or formal methodology, we're still doing what we've always done, picking up the slack in projects to get projects delivered (when the business don't have time to explain their problems to developers who can't listen).

It's all cyclical I just heard a presentation of dual track agile development, with a separate track for collecting requirements, it won't be long before the latest agile flavour then has a test track and stage-gates;-)
Reply | Reply with quote | Quote
0 # steve 2014-03-27 08:49
Thanks for the comments, Anthony. I agree with you completely. As for the cyclical nature of things, there was a time when the position of business analyst was an anathema to the agile community. Business analysts were looked on as obstacles and extra 'baggage' in the process. The developers should talk directly to the business people without an intermediary. Then things changed and even the staunchest anti-business analyst agilists have come out with suggestions on how to best use business analysts in their agile processes. It's not surprising to observe, as you have, agile teams having business analysts prepare detailed user stories in one sprint for the developers to execute in the next. I agree that having a "test' sprint follow might be the next evolution. And then we are back to a more waterfall approach. The purists howl in pain and the rest get the job done.
Reply | Reply with quote | Quote
0 # Shaun 2014-05-07 05:43
Thanks, for this nice sharing in these days agile business provides real world applications of organizational agile to get us started or deepen our agile practice. It provides insights from over 30 coaches, executives, developers and managers actively using agile in their organizations.
Reply | Reply with quote | Quote
+1 # Graeme Hoyle 2014-06-29 18:32
I'm going to stick my neck out here and say that the issue is not what a BA does or does not do but that in the IT industry far to much emphasis is put on requirements at the expense of design (analysis vs synthesis). In the ISEB book on business analysis (UK), there are plenty of chapters on requirements but scant mention of the design process that leads to an outcome that the customer wants. Design seems to be a piecemeal and ad-hoc activity that is almost peripheral to delivery. Without having an effective design process I find it hard to see how a successful delivery can be anything other than luck. The BA controversy is just a distraction.
Reply | Reply with quote | Quote
+4 # Bill 2014-07-31 10:21
Graeme, has great insight. I will be the 'bad guy' and take it a few steps further in a different, but parallel direction.

A PMP is not always a Project Manager.
A Project Manager is not always a PMP.
PMP is Program Management, not Project Mgmt.
A BA is not a PMP.
A BA is not a Project Manager.
Business Analysis is Business Analysis, Agile, Six Stigma and Lean have little to do with analysis expertise.
The industry is stocked with labels - get back to core competency. A B.A. is a facilitator of requirements gathering, analysis of need and translation/ove rsight of the business need and requirements so that a Project Manager can matrix manage the effort.
If the market continues to overlap and aggrandize all these functions, it will be even more convoluted than it is today - where any implementation seems to need 3 B.A.'s and 10 Project managers. I've never needed either function to get anything done, regardless of size or complexity - lack of knowledge and accountability from leadership and the worker bees doing the implementation work has dictated everything needs all these 'specialized' functions... The industry needs to grow up - it's not rocket science. It's having enough experience and exposure to the task to be able to instantly understand the need and make them salient requirements. Nothing more. It's really just that simple. And no, someone with a .arts degree, a regurgitated CBAP cert and a few years experience typically 'don't got' what it takes.
Reply | Reply with quote | Quote
-1 # kay 2014-09-01 22:35
Reply | Reply with quote | Quote
-1 # Akhilesh 2015-07-25 13:39
cool ... and then we fire the dev agile team one by one when they show a slow down or ask a hike .. anyways they become useless as we dont give them any business prescriptive ... cool
Reply | Reply with quote | Quote
-1 # Jim K. 2015-10-15 08:43
From the point of view of "Scrum" process, the dichotomy is resolved clearly by the role of PO, product owner. Scrum Master knows the team. PO knows and works the business. The seperation, and the co-operation is clear. I just got a requirement for a Scrum Master who is a Business Analyst. This is a conflict and violation of Scrum, though Scrum MUST HAVE a Product Owner, which is well-served by the Agile Business Analyst.
Reply | Reply with quote | Quote
0 # Sheila 2015-10-23 13:08
I must disagree, as I spend the last 2.5 years as both a BA and a SCRUM Master. We had a Product Owner and a Program Manager. At the day to day level, I was the one who knew Scrum and who is a Certified Scrum Master. There was no conflict.
Reply | Reply with quote | Quote
+5 # Paul 2015-11-19 04:30
I think it is very clear, and most don’t acknowledge, ‘’Agile’’ is a software development methodology and not a project methodology. To classify oneself as ‘’Agile’’ one segments oneself to the software development lifecycle, and is therefore unable to analyse the real problems within enterprise. BAs by their very nature should be holistic thinkers, and are often underutilised, or utilised incorrectly. Agile is a great methodology that gets products (solutions) out in the market quickly, allowing for adaptive improvements/in novations to be made based on analysing ‘’real data’’, user experience for example. Conclusion: the BA works on a problem long before and long after an agile team is spun up, therefore is an instrumental part to any organisation regardless of whether the solution be technical, process or structure.
Reply | Reply with quote | Quote
0 # Danny 2016-11-16 04:04
As an ex-developer, I'm yet to be convinced that Agile delivers anything more than the ability for Project Managers to say "Hey look - we're delivering stuff all the time!", regardless of whether that stuff is of a high quality, is necessary or meets the latest business needs.
Reply | Reply with quote | Quote
0 # Suresh 2017-03-04 21:04
Danny, if you think this then you haven't really experienced Agile done well. I think some agile projects can deliver poor quality and unneeded features but I have learnt that agile values can correct this. Delivering early means teams can test out whether customers really need a feature or not sooner than later, which is better than finding out too late. Regular showcases of completed software can also help better align delivery with company needs.
Reply | Reply with quote | Quote
0 # Yulia 2017-03-15 05:20
As a product owner or if you decided to become one, you probably read about Agile software development methodology. If you still hesitate about the viability of its usage or don't understand all terms then this article is for you. In our article, we'll clear up the concept of Agile, what roles are here, the risks, which exist in creating a product and how communication affects on the product:
Reply | Reply with quote | Quote

Add comment

Security code

search Articles

© BA Times.com 2016

DBC canada 250