INVEST is an acronym for Independence, Negotiable, Valuable, Estimable, Small, and Testable, which helps you to remember the criteria for the story. In order to have a good story, INVEST must be present because it is a criterion for a good agile story.

History of INVEST

The birth of INVEST is made possible by the article of Bill Wake in 2003. It serves as a requirement for the evaluator in checking a story. He based it in the SMART acronym, which is exclusively for building a good agile story. In the year of 2004, Mike Cohn’s “User Stories Applied” recommend INVEST as one of the techniques for an agile story.

What is INVEST

INVEST stands for criteria that serve as a requirement to have a good agile story. For a story to stand out, you should have the following:

  • I for independent: It says that your Product Backlog Item (PBI) made by you and not a copy or basses for the other PBI. You have to make your story that does not depend from the other stories to stand alone. A good agile can stand on its own.
  • N for Negotiable story is not a contract; it is a way to have a conversation with others and attain the best result. In making your agile story, there must be a presence of collaboration and discussion between the clients and the customers.
  • V for valuable: Think of the value why you want to do the story. The purpose of the story is to emphasize the role of the user among others. If it’s a business, then you have to emphasize the value of the business in your story.
  • E for estimable: Make an agile story that meets the guidelines of the appropriate size. Remember that user gets interested to the right length of the story and do not pay much attention to short or long stories.
  • S for small: Making the story done in many working days, the period that the expert suggests having a good agile story is 3 to 4 week. Just make it simple then stop.
  • T for testable: Provide all information of the PBI and other contents of the story to have fast testing and make more collaboration. With proper negotiation, you can test the effectivity of your story.

When to use it INVEST

INVEST is a requirement or criteria to meet the best agile story that you can make. It serves as a basis to have a good story that will get the interest of any. The product owner must have an idea about INVEST to meet the need of the team.

INVEST helps to overcome the hard part in making effective and good agile story. You can see an effective story with the products of the company posted on their website.

In the present, many changes and upgrade apply to have the best story. One of it is the INVEST, it is just one of the best in the present. There can be something out there as good as INVEST for criteria in making stories.

— Slimane Zouggari


Every company or business requires a good and effective tool in order to make the company successful. With the use of this tool, business and company management and planning could be done in an easy way. The success of the company lies with the greatness of Podio.


For several years Podio served clients who large and small businesses in different parts of the globe. As part of Citrix, it has developed a large communication for clients and company owners. Today Podio has a 99. 99 % rate of service to all its major clients.

What it does?

Podio is an agile software that makes use of the effective planning procedures of a company. These concern the updating of tasks, sharing information and project planning procedures. With the effectiveness of this tool, you have the big edge in having an efficient communication with the entire workforce, taking time in making updates and organizing planning methods. Thus, Podio makes your business grow and become successful.

You have the chance in sharing information, communicating with employees and making effective transactions if you will use Podio as a software tool. This would also provide an assurance of strategic planning, management and organizing procedures of the business.

For whom it is Useful

The collaborative software is useful to management leaders, planners and company owners.


  • You will have a collaborative way in communicating with your team by sending them in a single part of the office.
  • You will have the capacity to have a real time collaboration using mobile devices with your team or any company of business staff.
  • Collaborate with many clients and co-workers using the social media technology as a tool.
  • There is a free employee network for any employee
  • Each of the Podio users will have a great time due to the low costs it provides. Aside from this, you could also share tasks and communicate with them in an easy way


  • A company or business who has no sufficient resource will have a difficult time in using Podio.
  • This is mainly used in joint ways so there is no chance to strengthen  the individual skills of the employees will not be developed
  • Some of the features of Podio would not match the requirements of other companies.


This agile software could be purchased with the following plans:

Podio Lite 

This comes with a free package and suited for the use of 5 teams and smaller groups.

Podio Teams

The price of this could is down to $9 per month and a 20% price for group employees.

Podio Business

This can be availed by larger teams in an unlimited price. The standard cost will depend on the number of times the plan is used.


When it comes to collaborative software companies, Podio has competitors namely:

  • Trello
  • Team Work
  • JIRA
  • Base Camp
  • Zoho Wiki

The use of Podio in the work place provides a secure way of sharing information, files and documents. With this, you can be assured of a great and effective result for your company as a whole. Hence, partnerships and success are attained.

— Slimane Zouggari

SAFe: Strategic Themes

Lots of organizations utilize strategic themes in their strategy map. These themes could help organize those groups of related strategic goals, which work altogether to present a valuable and specific business result.
Let’s Take a Thorough Look of What Strategic Theme Really Is
Strategic themes are itemized, specific objectives, which link a SAFe Portfolio to the changing business strategy of an enterprise. It offer business context mainly for decision making in the portfolio at the same time affect investments in the Value Streams and be able to offer inputs to the following decisions:
– Program Backlog
– Solution
– Portfolio
– Budgets
– Economic Framework
These themes don’t need to restate the evident, as majority of elements of the vision of portfolio are comprehended through context. In addition, portfolios stakeholders are typically understand well what the portfolio is really for, handle, and create their own visions and goals.
What does it offer?
To a certain extent, strategic theme is capable in providing the enterprise along with the differentiators that is going forward coming from the present state to the unknown state. These aid drive competitive differentiation as well as innovation, which is achievable through efficient portfolio solutions.
In addition to that, strategic themes are crafted as a result of a collaborative and structured planning process – one, which includes the executives and fiduciaries of the enterprise and the key stakeholders coming from every portfolio.
Devising Strategic Themes
Creating strategic themes is one practice in strategy formulation; however, it is not the state of SAFe portfolio context. According to the guidance of a certain enterprise, this theme is an output of a collaborative process, which is a kind of process wherein the enterprise portfolio stakeholders are able to work along with portfolio stakeholders to analyze a collection of inputs prior to getting at conclusions.
Following are some common samples of strategic themes:
(1) Create shingle sign-on in the portfolio applications into the internal enterprise apps
(2) Online retailer or lower warehouse costs
(3) Execute operational and product support for securities in FOREX trading (security company)
(4) Demand to a younger demographic or online retailer
(5) Regulate on three (3) software platforms
How Strategic Themes Affect the Portfolio
Strategic themes are one of those primary inputs into the portfolio vision at the same time plays as elements of Economic Framework, which affects Agile Release Train budgets, Value Streams, individual ART vision, Portfolio Backlog and Roadmap.
 Economic Frameworks – it affects some of the major parameters such as product cost, cycle time or development, risk, product value and development expense
 Value Streams – such theme affect value stream budget that present the spending s well as the personnel allocations needed to build the portfolio vision.
 Vision & Priorities – here, the Product and Solution Management was able to apply such them to affect the roadmap.
 Portfolio Backlog – themes offer decision making filters on the system of Portfolio Kanban thus affecting the portfolio backlog.
Keep in mind that strategic themes are quite essential tool for corresponding strategy to the whole portfolio. It offers a memorable, simple reference frame and at the same time must seep into the thinking of everybody included in Solution delivery.

SAFe: Non-functional requirements

If there’s any one thing that all projects should have to ensure a successful project outcome, that is a comprehensive and sensible collection of non-functional requirements, aside from functional requirements.
NFR or non-functional requirements is responsible for describing how the system runs. Essentially, it identifies how the system should work and that is a constriction on the behavior of the system. Also, you can think of NFR as a quality attribute of a system. It covers all the remaining necessities which are not comprised by the functional requirements. Instead of specifying specific behaviors, they identify criteria that judge the system’s operation.
What are the typical non-functional requirements?
There are many typical NFR included, some of them include:
• Performance
Requirements on resources required, throughput, static volumetric, utilization, benchmark utilizations, response time or whatever thing that is having to do with performance.
• Precision and accuracy
This refers to the precision and accuracy of the data. However, each one is advisable to become beware of the one hundred percent requirements, as they frequently cost great amount of money.
• Modifiability
This is the requirements about the effort needed to make software changes.
• Reliability
Requirements on how frequent the software fails. Often, the measurement is expressed in mean time between failures (MTBF). The description of the failure should be clear. People also get confuse between reliability and availability, which, in the first place should not because they are quite different types of requirements. Make sure to identify the results of software failure, a strategy to detect error, a correction strategy and how to protect from failure.
• Portability
This is the required effort to move the software into various target platforms. Mostly, the measurement is person-months or percent of elements that need altering.
• Usability
The requirements on how challenging it will be to learn and run the system. Often, the requirements are conveyed in learning time or other similar metrics.
• Security
One or more requirements on system protection and its data. The measurements may be expressed in a range of ways such as time, skill level and effort, among others, to get in the system.
• Integrity
Integrity requirements describe the system’s security attributes, which restricts access to data or feature to particular users as well as protect the privacy of data entered in the software.
• Robustness
A robust system is the one responsible for handling error conditions in a graceful way, with no failure. This includes a forbearance of invalid data, unexpected operating conditions and software detects.
There are other typical NFR included, and some of them are capacity, scalability, availability, maintainability, recoverability, serviceability, environmental, manageability, regulatory and interoperability.
With the increasing demand in this system, more and more companies are trying to get the interest and trust of clients, promising them a high quality service and product. But if you really want total assistance, Scaled Agile Framework is the best partner you can depend on with your non-functional requirements.
SAFe is a freely, online revealed expertise base of credible and proven success patterns when it comes to implementing Lean-Agile systems and software development at company scale. It offers extensive guidance for project at the enterprise Program, Value Stream, Portfolio and Team levels.

SAFe: epic abstract

Epic Abstract
Epics are considered as containers intended for important initiatives which would help in guiding value streams through larger aim of a portfolio. In doing so, they would drive more of the economic value for a certain enterprise. They are as well considered to be large and commonly crosscutting at the same time crossing numbers of value streams and also ARTs or the Agile Release Trains. They are also investment intensive as well as far ranging in impact like formulation as well as analysis of impact, cost and opportunity as a serious matter. And Epics as well need lightweight business case as well as financial approval prior to implementation. The two types of epics are enabler epics and business epics and are to appear in the value stream, portfolio and program levels.
Portfolio business epics and Enabler epics are considered as the largest epics that would capture that biggest crosscutting initiative which happen in a portfolio. Business epics are to bring business value directly while enabler epics are utilised in order to evolve the Architectural Runway therefore supporting the upcoming business epics. So, epics are captured initially within the Portfolio Kanban and would move into the system under WIP limits or the work-in-process. And this would help in reassuring that the ones doing the work would have some time needed in order to conduct a responsible analysis.
In connection, Kanban system is about helping manage the expectations intended for reasonable scoping as well as time frames intended for implementing the new ideas of a certain business. The final decision as for the actual implementation of every epic would be subjected into the authority of the PPM or Program Portfolio Management. Once resources are available, those decision makers could now choose from the numbers of business opportunities for there would be numbers of analysed epics within the backlog any time. And the epics that are being approved would proceed to Portfolio Backlog, waiting for the implementation capacity.
Epics are indeed the most important initiatives in a portfolio that’s why they should be analysed carefully prior to the implementation. The owners of epic should also take into responsibility for the said important task at the same time the architects of the enterprise would shepherd the enabler epics which support the technical considerations for the business epics. Those most worthy epics would be passed to analysis once space would become available within that queue. And from there, effort as well as economic impact are defined a lot better, cost estimates are as well established, WSJF prioritization would be refined and also lightweight business case will be developed.
Some of the things included in the analysis would be the following:
• Workshops along with business stakeholders for the purpose of describing and understanding the business benefits of the business epic
• Implementing spikes, exploration and research activities through teams
• Define the success criteria for the epic
• Workshops for architects as well as system engineering right from value stream and program levels and to the agile team allowing them to understand the implementation of the impact and effort in recent solutions and also some other related SMEs could be included
• Develop concrete examples in order to resolve certain ambiguities
And the result of the said analysis phase would be a lightweight business case which captures the results of the analysis such as refined description, estimates of time and cost of implementation, success criteria and also program impact.

SAFe: Enterprise Abstract

Every SAFe portfolio is comprised of a collection of Value Streams and added constructs essential to offer governance and funding for the services, products as well as Solutions, which the Enterprise must fulfill.
Along with those small and medium-sized businesses today, one single SAFe portfolio could generally be utilized to direct the whole technical solution set. On the other hand, to those bigger businesses, normally those along with over 500 to 1,000 technical practitioners, there could be countless portfolios, one for every line of business:
 Smaller Business
One ART, 1 value stream, value stream level not required
 Larger Business
Countless value streams where some comes along with different ART and complete solution context required
 Largest Business
Different SAFe portfolios by which some smaller, some larger
Essential Guidance on How Enterprise Could Communicate and Define
What does a SAFe Portfolio Symbolize?
This portfolio represents the utmost and highest level of issues articulated within SAFe. In addition to that, each program involves primarily a collection of Value Streams, which offer value. The level talks about the constructs necessary, which includes:
(1) Epics
(2) Portfolio Backlog
(3) Lean-Agile Budgeting
(4) Portfolio Kanban System
(5) Program Portfolio Management or PPM, etc.
Nevertheless, bear in mind that every portfolio is present for a one reason and that is to complete or accomplish its contribution in the direction of realizing the whole Enterprise strategy. How could this be done? The answer to that question is very simple. This is accomplished through aligning every vision of the portfolio into the strategy of the enterprise.
The main mechanisms for making this are those value streams, the whole portfolio budget, strategic themes, which correspond to changing strategic intent as well as to the constant feedback using portfolio context.

Know more about Single Enterprise SAFe – Things to Consider
1. Bigger Enterprises Have Countless Instances of SAFe – In order to obtain larger purposes, enterprise would have countless SAFe portfolios, all having its own budget as well as strategic themes that represent that portion of the unit of the business strategy.

2. Portfolio Contexts Updates Enterprise Strategy – Development strategy must have continuous communication, collaboration as well as alignment from and with the downstream portfolios. In a nutshell, this needs complete and full understanding of the portfolio context that involves:

• Qualitative Data which includes weaknesses, strengths, market, threats, opportunities, analysis and accumulated solution as well as business knowledge of portfolio stakeholders.

• Key Performance Indicators that is present on the portfolio in order to present essential feedback into the financial and qualitative measure like market share, innovation counting, customer net promoter score and so much more.

3. Strategy Formulation – Understanding and defining the strategic themes and portfolio budget is one of the important exercises when it comes to strategy formulation.

4. Decentralize Execution – According to the Principle #9 of SAFe, which is Decentralize Decision Making, the creation or formulation of the business strategy is mainly a centralized however collaborative concern that the enterprise fiduciaries as well as key portfolio stakeholders serves as a central role. In addition, execution of the solution strategy, nevertheless, is decentralized into the portfolio and is sustained by constant feedback, transparency, right portfolio metrics and KPIs.

SAFe: enablers

When it comes to software engineering, enablers are the responsible one. Enablers are technical creativities meant to support and allow the development of business initiatives. They satisfy application domain requirements which include cloud infrastructure, big data processing and internet-of-things.
Enablers are highly regarded as work items that bring and capture visibility to any work essential to support delivery and development of future business structures. Primarily, they are used for system, exploration and solution architectural progress, as well as to improve testing and development environments. They are all treated like any other value added growth activities, and are therefore bounded to tracking and visibility, estimating, feedback, WIP limits and result presentation.
What are the types of enablers?
There are many types of enablers, namely:
 Enabler features and capabilities
This occurs at the Program and Value Stream levels, in which they capture project of that kind. They are sharing similar attributes, since these enablers are a kind of capability or feature. The similar attributes they possess include acceptance criteria and benefit statements. Also, they should be structured in order to match in one PI.
 Enabler epics
Enabler epics are an epic kinds. They have a tendency to intersect the PIs and value streams. A lightweight business case should also include to support their application and are discovered and tracked using the portfolio Kanban system.
 Enabler stories
These are a story type, and should conform to iterations. Though they may not necessitate user voice set-up, but they have acceptance measures to clarify the support and requirements testing.
Enablers are follow, prioritized and written the same rules as their corresponding Capabilities, Epics, Stories and Features. For instance, Enabler Features and Features are written through a Benefits and Features matrix, use story estimation points, WSJF for arrangement and have criteria for acceptance.
Managing and Producing Enablers
Most of the enablers are made when business initiatives, which creates their way through various Kanban systems, need examination enablers to validate the solution or need, infrastructure enablers to become prepared to integrate, test and develop the initiatives, as well as architectural enablers to cover the runaway.
Often, system engineering or architects create enablers at different levels, whether by Solution and System Engineering/Architects at the Program and Value Stream Levels or Enterprise Architects at the Portfolio Level. The architects or engineer who builds the enablers steer them with the Kanban systems, which offers the information required to implement and estimate, and guidance required to analyze them.
Some enablers, on the other hand, emerge nearby from the necessities of value streams or professionals to improve the current solution. To help your business, Scaled Agile Framework has created an excellent and superior service suitable to the needs and personal preference of people. You can choose a project you want for your enterprise and let SAFe do the hard work on your behalf.
Whether that is for Value Stream, Program, Portfolio or Team levels, SAFe has the knowledge and expertise to completely do the task assigned to them. Increasingly more large and small enterprises are able to get an excellent business benefits from partnering with SAFe.

Disciplined Agile Delivery

An Introduction to Disciplined Agile Delivery
While organizations today recognize the benefits, for software development projects, practices of agile methods such as Scrum, Extreme Programming (XP), Lean or Agile Software Development Modeling; there is also a concern about how to scale agile practices at the enterprise level where projects are larger, more dispersed teams work and the architectural, technological and even contractual restrictions are very demanding. The basic methods require important to scale beyond eight teams of people working together in the same place settings.
The DAD can be defined as an iterative and incremental approach to software development that produces regularly and cost-effectively high-quality solutions and at the right time, through a life cycle oriented to risk and the solution value. It is performed in a highly collaborative, disciplined and self-organized way within a governance framework that has active participation of those involved to ensure that the development team understands and applies the evolving needs of the form of actors to maximize the value of business provided by the product (software).

The DAD is a methodology created by IBM Rational that can be seen as an expansion to the Scrum lifecycle in three aspects:
• Explicite phases of the project, recognizing that the delivery of agile project is iterative and also sequential;
• It includes requirements and architecture forecasting practices to the project start to increase the chance of the correct product construction, and contemplate delivery practices of the product in production;
• It includes more robust agile practices (AMBLER, 2012).
The formation of an effective agile team is a crucial point in the DAD and there are some indications that an effective Agile team was formed:
• He has the expertise to get the job done;
• They are as small as possible;
• There are people dedicated to the project;
• It has a unique Product Owner;
• It has a unique team leader (which is not the product owner);
• It has general analysts;
• May include experts, but in the direction of becoming generalists;
• They are self-organized into an appropriate framework for governance.
The more we deviate from this situation, the higher the project risk.
In the image below, we can see the life cycle DAD and its activities. Notice how are explicit project phases (Design, Construction and Transition).

In Disciplined Agile Delivery roles are divided into primary and additional roles.
Primary roles:
• Stakeholders;
• Team Leader;
• Product Owner;
• Team member Nimble;
• Architecture Owner.
• Additional roles:
• Expert in the field;
• Expert technical;
• …
Stakeholders are the people who affect or are affected by the success of the system.
The Product Owner, Scrum as in promoting the goals and vision of the product so that the team can make decisions. He owns the product backlog, defines the scope of a release and when the product is ready to be delivered and deployed.
The Team Leader is responsible for the success of the project and how the ScrumMaster in the Scrum framework facilitates cooperation between roles and functions, remove barriers and problems, protect the external interference team and ensure that the process is followed.
Members of Team Agile are the other members of the team. Also known as developers are generalists, collaborative and self-managed.
The Architecture Owner is responsible for the architecture of the system or subsystems in which the team is working as part of a team of Architecture Owners. He mentor and guides developers in architectural problem and is also a technical team leader. It has the final word on the architecture, but seeks a collaborative approach with your team.
As to additional roles, they are typically large team. The Expert in the Field knows details that are not always the end user domain or stakeholders. We can illustrate this role in the figure of an expert in finance charges. The Expert Technical features detailed areas of expertise, for example, create builds scripts or database. Independent testers are used by teams working regulatory standards or domains and complex technologies. The team may still need Integrators, responsible for the integration of complex subsystems and experts that can focus on issues such as security.

–Slimane Zouggari

DSDM: the 9 principles

The whole method is based on nine principles, all of which are to be applied, the first four define the foundations on which DSDM was built and the remaining five provide the basic principles for the structure of the method.
1. Active involvement of users is essential
This is the main principle. The involvement is not only active, but even proactive.
In DSDM this is the contribution of users evenly.
2. DSDM teams must be empowered to make decisions
Team members must be able to make quick decisions on the way forward.
Characteristic of DSDM is indeed a tight schedule. There is no time for long decision-making. The team members must have clarity about the boundaries, within which they can operate. An important limitation is, of course, the budget.
3. Frequent delivery of goods is of essential importance
By planning a regular completion (say weekly) of something tangible and sight perch one creates a safety net for reversal of bad decisions that managers do not feel the controls to be lost. The products do not have to be complete, as long as they progress in the proper direction show.
4. Fitness for business purposes is essential for the acceptance of products
The principle means that the developer does not remain stabbing at some point because he wants to make gold rimmed solution. The suitability for business purpose has starting point, certain technical issues can be postponed.
5. Iterative and incremental development is necessary in order to converge to right solution
If the team includes users who provide feedback almost immediately on the work of the developers, it is possible to carry out system development step by step instead of in one go. Because systems are developed piecemeal, DSDM ensures that errors are detected early
6. All changes during development are turning back
This means that there has to be immaculate from a management of all software and related documentation.
7. Requirements are set at high level
Demands collected during the Business Analysis to determine the scope of the project. These requirements should be clearly defined well.
8. Testing is integrated in the life cycle
The philosophy of DSDM is “test as you go.” All tests, including acceptance testing, are progressively implemented during the project.
9. A collaborative and cooperative attitude of all stakeholders is essential
Not only collaborate and cooperate are important, but all is equally important. Participants in this approach become involved. Any existing artificial partitions between and within departments work mainly in DSDM.

–Slimane Zouggari