Gestão de backlog – Epic Roadmap, WI relationships e personas no Azure DevOps

Já discutimos sobre o uso do Azure DevOps como plataforma de ciclo de vida do desenvolvimento e a estruturação do backlog na ferramenta (Epic – Feature – User Story – Tasks) de acordo com o seu process template.

Na área de Boards do Azure DevOps, temos alguns novos recursos no Marketplace para apoiar a visualização e gestão das atividades dos times. Selecionei três deles que são bem interessantes:

Crie então a estrutura do seu Time de Projeto no Azure DevOps (Boards > Backlogs). Veja na imagem abaixo que a relação entre Epic – Feature (Requirement) – User Story é de Parent. 


Feature timeline and Epic Roadmap

Após a estruturação do backlog, ainda em Boards > Backlogs, veja que as guias de “Feature Timeline” e “Epic Roadmap” foram criadas (após a instalação da extensão do Marketplace). A visão é das User Stories em relação a Sprints que serão desenvolvidas. Este roadmap ajuda o time a visualizar a entrega das funcionalidades do projeto.


Visualize work item relationships

Após a instalação da extensão no Marketpace, acesse as opções do Work Item (conforme imagem abaixo) e utilize Visualize. Em seguida, veja que será exibido a estruturação do seu backlog, bem semelhante ao FBS (Feature Breakdown Structure), muito utilizado para ajudar o time a melhorar a compreensão do produto e requisitos.




Por fim, a criação de Personas ajuda a representar o usuário no sistema, descrevendo seu papel e necessidades. Instale a extensão do Marketplace (conforme link no início do artigo) e acesse o novo recurso “Personas” que será exibido, conforme abaixo.

Clique em + Add para adicionar uma nova Persona. Preencha o Nome, Tag, Descrição e Foto conforme necessidade do projeto.


Após ter criado a Persona, você consegue utilizar e vincular em qualquer Work Item. No exemplo abaixo, estamos associando quais Personas são afetadas pela aquela atividade.


Book Review: “Lean Enterprise: How High Performance Organizations Innovate At Scale”

Book Review: “Lean Enterprise: How High Performance Organizations Innovate At Scale” (Jez Humble, Joanne Molesky, Barry O’Reilly)


Chapter 1 – Introduction
Starts explaining the importance of management and people and an approach in Toyota Production System. An alternative to command and control and other highlighted topics are:

A Lean Enterprise is primarily a human system:

  • Pathological organizations: are characterized by large amounts of fear and threat. People often hoard information or withhold it for political reasons, or distort it to make themselves look better.
  • Bureaucratic organizations: protect departments. Those in the department want to maintain their “turf”, insist on their own rules, and generally do things by the book – their book.

How organizations process information:

Pathological (power-oriented) Bureaucratic (rule-oriented) Generative (performance – oriented)
Low cooperation Modest cooperation High cooperation
Messengers shot Messengers neglected Messengers trained
Responsibilities shirked Narrow responsibilities Risks are shared
Bridging discouraged Bridging tolerated Bridging encouraged
Failure leads to scapegoating Failure leads to justice Failure leads to enquiry
Novelty crushed Novelty leads to problems Novelty implemented

The three gaps, and how to manage them:

Effects gap Knowledge gap Alignment gap
What is it? The difference between what we expect our actions to achieve and what they actually achieve The difference between what we would like to know and what we actually know The difference between what we want people to do and what they actually do
Scientific Management Remedy More detailed controls More detailed information More detailed instruction
Auftragstaktik remedy “Everyone retains freedom of decision and action within bounds” “Do not command more than is necessary or plan beyond the circumstances you can foresee” “Communicate to every unit as much of the higher intent as is necessary to achieve the purpose”
Directed opportunism remedy Give individuals freedom to adjust their actions in line with intent Limit direction to defining and communicating the intent Allow each level to define how they will achieve the intent of the next level up, and “backbrief”

The key to the Principle of Mission is to create alignment and enable autonomy by setting out clear, high-level target conditions with an agreed time frame. This principle is applied in multiple contexts:

  • Budgeting and financial management
  • Program management
  • Process improvement


Chapter 2 – Manage the Dynamics of the Enterprise Portfolio

This chapter explain the lifecycle of businesses and how companies can balance the exploration of new business models with the exploitation of proven ones.

Technology adoption lifecycle

Technology adoption lifecycle

Once the market has assimilated a disruptive new technology or idea, a whole range of product offerings gets spawned.

Exploring new opportunities and exploiting existing ones are fundamentally different strategies requiring different structure, competencies, processes, and mindset. It is hard to overemphasize this key point: management practices that are effective in the exploit domain will lead to failure if applied to exploring new opportunities – and vice versa. The difference between these two domains:

Explore Exploit
Strategy Radical or disruptive innovation, new business model innovation Incremental innovation, optimizing existing business model
Structure Small cross-functional multiskilled team Multiple teams aligned using Principle of Mission
Culture High tolerance for experimentation, risk taking, acceptance or failure, focus on learning Incremental improvement and optimization, focus on quality and customer satisfaction
Risk management Biggest risk is failure to achieve product / market fit A more complex set of trade-offs specific to each product / service
Goals Creating new markets, discovering new opportunities within existing markets Maximizing yield from captured market, outperforming competitors
Measure of progress Achieving product/market fi Outperforming forecasts, achieving planned milestones and targets

Exploring New Ideas

Less than 50% of startups are alive five years after they start. The Lean Startup details a method for working in conditions of extreme uncertainty – to discover and operationalize new and potentially disruptive business models, and quickly discard those that will not work.

Every entrepreneur has a vision of their business. And for this vision to become reality, there are two key assumptions that must be tested:

  • Values hypothesis: asks whether our business actually provides value for users by solving a real problem.
  • Growth hypothesis: tests how fast we can acquire new customers and whether we have that.

Investing a fixed amount of time and money to investigate the economic parameters of and idea-be it a business model, product, or an innovation such as a process change-is an example of using optionally to manage the uncertainties of the decision to invest further. We limit our maximum investment loss (“downside”) on any individual idea, with the expectation that a small number of ideas will pay off big time, and offset or negate investment in those that did not.

The principle of optionality
The principle of optionality

The other part in this chapter is related to Enterprise Portfolio – balancing (using an economic model), matrix portfolio management (1. Emerging 2. Growth 3. Mature 4. Decline), managing a portfolio with the three horizons model (1. Current Business 2. High Growth Businesses 3. Growth Options).



Chapter 3 – Model and Measure Investment Risk

Here is presented the principles and concepts that enable us to take a systematic approach to managing the risk of planned work, by gathering information to reduce uncertainty. Model Investment Risk using Business Case or Monte Carlo are discussed in this chapter to verify how useful they are in scenarios of uncertainty.

We should stop using the word “requirement” in product development, at least in the context of nontrivial features. What we have, rather, are hypotheses. In the case of business model and product innovation, the Lean Startup movement provide us with a framework for operating in conditions of extreme uncertainty:

  • Do not spend a lot of time creating a sophisticated business model. Instead, design a simplified business model canvas with captures and communicates the key operating assumptions of your proposed business model.
  • Gather information to determine if you have a problem worth solving.
  • Then, design an MVP (minimum viable product)-an experiment designed to maximize learning from potential early adopters with minimum effort.
  • Throughout this process, update the business model canvas based on what you learn from talking to customers and testing MVPs.

Traditional product lifecycle versus Lean Startup lifecycle:

Traditional project-planning process Lean Startup discovery process
What data do we have to make the investment decision? A business plan based on a set of untested hypotheses and assumptions, backed by case studies and market research Real data based on evidence complied from a working product or service tested with real customers
What happens next? We must create detailed requirements, if we haven’t already, and then starts a project to build, integrate, test, and finally release the system We already have a validated MVP which we can build upon immediately with new features and enhancements based on customer feedback
When do we find out if the idea is any good? Once the project is complete and the product or service is live We already have this evidence based on the data we have collected

Principles for exploration
The OODA loop, a model of how humans interact with their environment which forms the basis of Boyd’s theory of maneuver warfare. OODA stands for observe, orient, decide, act, the four activities that comprise the loop.


Chapter 4 – Explore uncertainty of detect opportunities

In the chapter four, tools and techniques are shared to safely create and test hypotheses to solve real business problems identified and validated in our customer development process. Discovery is a rapid, time-boxed, iterative set of activities that integrates the practices and principles of design thinking and Lean Startup, used intensively at the beginning of the explore phase of a new initiative.

Creating a shared understanding (Dan Pink – Drive):

  1. Success requires a shared sense of purpose in the entire team
  2. People must be empowered by their leaders to work autonomously to achieve the team objectives
  3. People need the space and opportunity to master their discipline, not just to learn how to achieve “good enough”

With workshops, you can co-create ideas aligned to business goals. The process, starting with divergent thinking until convergent thinking can generate multiple ideas for discussion and debate.

Structured exploration with divergent and convergent thinking

Structured exploration with divergent and convergent thinking

The Business Model Canvas can share the understanding about business problem to inform the Business Plan. It includes nine essential components of an organization’s conceptual business model – customer segment, value proposition, channels, activities, resources, partnerships, cost and revenue.

Business Model Canvas

In this chapter, also is covered MVPs and how to accelerate experimentation with them. Cagan defines an MVP “the smallest possible product that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available-also known as valuable, usable and feasible”.

MVPMinimum Viable Product: build a slice across instead of one layer at a time

example set of types of MVPsexample set of types of MVPs 02example set of types of MVPs 03
An example set of types of MVPs


Chapter 5 – Evaluate the product/market fit

This chapter discuss how to identify when a product/market fit has been achieved and how to exit the explore stage and start exploiting our product with its identified market. Also, how to use customized metrics to understand whether we are achieving measurable business outcomes while continuing to solve our customers problems by engaging them throughout our development process.

Some examples of vanity metrics and corresponding actionable metrics:

vanity versus actionable metricsExamples of vanity versus actionable metrics

Example innovation scorecardExample innovation scorecard

The pirate metrics helps you to model any service-oriented business. Measuring pirate metrics for each cohort allows you to measure the effect of changes to your product or business model, if you are pivoting. The Votizen’s pirate metrics represents the effect of incremental change and pivots.

AARRR pirates

A story map can help you to tell the narrative of the Runway of our vision. Can be used to plan e prioritize by visualizing the solution as a whole. It provides an effective means to communicate the narrative of our solution to engage the team and wider stakeholders and get their feedback.

A user story map

The five critical enablers of growth when transitioning from explore to exploit are:

  • Market
  • Monetization model
  • Customer adoption
  • Forget “big bang” launches
  • Team engagement



Chapter 6 – Deploy Continuous Improvement

In most enterprises, there is a distinction between the people who build and run software systems and those who decide what the software should do and make the investment decisions. Ultimately, we aim to remove this distinction. In high performance organizations today, people who design, build, and run software-based products are an integral part of business.

In this chapter is described how to achieve the balancing (the work we do to improve our capability against delivery work that provides value to customers) at program and value stream levels, by putting in place a framework called Improvement Kata. The other part, covers practices in CI/CD as branching versus trunk-based development and other. For more details, I recommend to access my blog.

A good example, in the HP LaserJet Firmware Case Study, we can see how allocating costs to the activities the team is performing.

% of costs Activity
10% Code integration
20% Detailed planning
25% Porting code between version control branches
25% Product support
15% Manual testing
~5% Innovation

The Improvement Kata needs to be first adopted by the organization’s management, because it’s a management philosophy that focuses on developing the capabilities of those they manage, as well as on enabling the organization to move towards its goals under conditions of uncertainty. There are four stages that we repeat in a cycle:

The Improvement KataThe Improvement Kata

  • Understand the direction: derived from the vision set by the organization’s leadership.
  • Grasp the current condition: after the direction, we incrementally and iteratively move towards it at the process level.
  • Establish the next target condition: as we continuously repeat the cycle, we reflect on the last step taken to introduce improvement.
  • Iterate toward the target condition

Three years after the initial measurements (in HP LaserJet case), a second activity-accounting exercise offered a snapshot of the results the FutureSmart team had achieved with their approach:

% of costs Activity
2% Continuous integration
5% Agile planning
15% One main branch
10% Product support
5% Manual testing
23% Creating and maintaining automated test suites
~40% Innovation

Chapter 7 – Identify value and increase flow

Most enterprises are drowning in a sea of overwork, much of which provides little value to customers. In the previous chapter was showed how to implement a program-level continuous improvement strategy to improve productivity and quality and reduce costs. In this chapter, the purpose is showing how the five lean principles can be adopted to reduce the cycle time, increasing quality and return on investment.

In high-performing organizations, leadership and management has a sharp focus on the value the organization is creating for its customers.

The value stream map helps to reflect the current condition in a determined product or service we want to evaluate. This exercise must gather people from every part of organization involved in the value stream.

value stream mapOutline of a value stream map showing process blocks

After concluded, we record three key metrics:

  • Lead time: the time from the point a process accepts a piece of work to the point it hands that work off to the next downstream process
  • Process time: the time it would take to complete a single item of work if the person performing it had all the necessary information and resources to complete it and could work uninterrupted
  • Percent complete and accurate (%C/A): the proportion of times a process receives something from an upstream process that it can use without requiring work

Also is presented Kanban concepts to share a comprehensive way to manage the flow of work:

  • Visualize workflow (creating a board)
  • Limit WIP (work in progress)
  • Define classes of service (for different types)
  • Create a pull system (by agreeing on how work will be accepted into each process block when capacity becomes available)

And a Cost of Delay – a framework for decentralizing economic decisions, to identify and prioritize the work with the highest opportunity cost.

cost of delay.png

How do we prioritize Tasks A and B with Cost of Delay? 

Chapter 8 – Adopt Lean Engineering Practices

“Cease dependence on mass inspection to achieve quality. Improve the process and build quality into the product in the first place”. W. Edwards Deming.

In this chapter there are important concepts to allow the organizations deploy new releases in production frequently, necessary to test ideas with real users and enable effective innovation process (learn and update based on feedback). For more details from other concepts like continuous integration, test automation, continuous deliver and deployment pipeline, access my blog.

Deployment g-forcesDeployment g-forces


Chapter 9 – Take an Experimental Approach to Product Development

Up to now, the others chapters show how to improve the speed at which can deliver value to customer. In this chapter, the focus is to discuss alignment – how to use capabilities we have developed to make sure we are building the right things for customers, users, and our organization.

So, concepts as creating hypothesis, hypothesis-driven development and user research are described to focus on the outcomes we wish to achieve, rather than solutions and features.

user research

Different types of user research

Also for more details, please visit my blog.

Chapter 10 – Implement Mission Command

The organizational and architectural concerns are often the biggest barriers to executing the strategy for moving fast at scale based on the principles of Mission Command (described in Chapter 1). Amazon has a famous memo to technical staff directing them to create a service-oriented architecture:

  • All teams will henceforth expose their data and functionality through service interfaces
  • Teams must communicate with each other through these interfaces
  • There will be no other form of interprocess communication allowed. The only communication allowed is via service interface calls over the network
  • It doesn’t matter the technology they use. HTTP, Corba, Pubsub, custom protocols.
  • All services interfaces, without exception, must be designed from the ground up to be externalizable
  • Anyone who doesn’t do this will be fired

A key principle of service-oriented architecture (SOA) is decomposing systems into components or services. Each component or service provides an interface (also known as an API – application programming interface) so that other components can communicate with it.

Here are some strategies enterprises have successfully applied to create autonomy for individual teams:

  • Give teams the tools and authority to push changes to production
  • Ensure that teams have the people they need to design, run and evolve experiments
  • Ensure that teams have the authority to choose their own toolchain
  • Ensure teams do not require funding approval to run experiments
  • Ensure leaders focus on implementing Mission Command

traditional enterprise organizationExample of traditional enterprise organization

product teamsProduct teams working together, with a service layer for performing deployments

Creating small, autonomous teams makes it economic for them to work in small batches. When done correctly, this combination has several important benefits:

  • Faster learning, improved customer service, less time spent on work that does not add value
  • Better understanding of user needs
  • Highly motivated people
  • Easier to calculate profit and loss



Chapter 11 – Grow an innovation culture

Culture is the most critical factor in an organization’s ability to adapt to its changing environment. The main topics in this chapter are:

  • Model and measure your culture: important to consider layers of organizational culture
    • Artifacts: visible, observable aspects of culture such as organizational structures and processes, and how people dress and behave. Hard to decipher.
    • Espoused values: strategies, goals, philosophies, such as the “value statements” you find in the company lobby
    • Underlying assumptions: unconscious beliefs, perceptions, thoughts, feelings (which ultimately govern values and behavior)
  • Change your culture: Old and new approaches to cultural change – Shook offers his own interpretation of Schein’s model, showing how people normally approach cultural change in contrast to the approach taken at NUMMI.
    Shook Change your culture
  • Make it safe to fail
  • There is no talent shortage: Dweck’s two mindsets, showed through a series of experiments that our mindset determines how you decide your goals, how to react to failure, what are our beliefs about effort and strategies, and what is our attitude towards the success of others.
    two mindsets
  • How Google recruits
    how google recruits.jpg
  • Growing talent: there are many ways in which enterprises can invest in people
    • Help employees create and update personal development plans
    • Separate performance reviews from compensation reviews
    • Facilitate regular feedbacks
    • Give employees access to training funds
    • Give employees time to pursue their own goals
  • Eliminate hidden bias: the effects of implicit gender bias on hiring. Here is a selection of strategies that haven proven useful
    • Ensure equitable pay
    • Create target conditions for recruitment and promotion
    • Monitor tenure, rate of advancement and job satisfaction
    • Regularly review policies, interactions and HR processes

effects on hiring

Chapter 12 – Embrace Lean Thinking for Governance, Risk and Compliance

The chapter is to guide you through the maze that is GRC (Governance – Risk – Compliance), particularly as it relates to managing the concepts and practices required to be a lean enterprise. Governance is about keeping our organization in course. It is the primary responsibility of the board of directors, but it applies to all people and other entities working for the organization. It requires the following concepts and principles to be applied at all levels:

  • Responsibility
  • Authority and accountability
  • Visibility
  • Empowerment
  • Risk management and compliance

Apply Lean Principles to GRC processes: visualizing the value stream, increasing feedback, amplifying learning, empowering teams, reducing waste and delays, limiting work in process, making small incremental changes, and continuously improving to achieve better outcomes.

Good Governance requires everyone to focus on discovering ways to improve value and provide accurate information on which to base our decisions. We start with leadership and direction from the Board and Executives, and rely the ability of employees to embrace their responsibility to make good decisions at work. A culture of openness, trust, and transparency is required for good governance.


Chapter 13 – Evolve Financial Management to drive Product Innovation

Centralized budgeting process are typically used to plan, forecast, monitor and report on the financial position and overall performance of an organization. However, the traditional annual budget cycle can easily:

  • Reduce transparency
  • Remove decision from the people doing the work
  • Direct costs away from value creation
  • Measure performance by the ability to please the boss or produce output

budget purpose
Approaches to achieving the goals of budgeting

The Dynamic Resource Allocation creates more frequent checkpoints for funding decisions, and each decision has less risk associated with it. All decisions are based on the empirical evidence, so they become easier to make. When done correctly, access to funding expands to more teams, gets more frequent, has less associated risk, and brings better results. We thus encourage more innovation and reduce financial risk associate with large initiatives.

dynamic resource allocationDynamic resource allocation

In the other part, the chapter describe:

  • Avoid using budgets as the Basis for performance measurement: bonuses and rewards for good bottom-line financial results work better when they are shared equally. Working teams will eventually cripple the organization by inertia and subterfuge when their contributions are not acknowledged and rewards are based on a process perceived as unfair.
  • Stop basing business decisions on CAPEX versus OPEX: there are tax advantages and positive financial impacts from reporting organization expenditures appropriately in these different buckets, so a lot of attention is paid to it.
  • Modify your IT Procurement Processes to gain greater control over value delivery: this painful, highly detailed contractual process has several negative side effects
    • It’s a poor way to manage the risks of product development
    • It favors incumbents
    • It favors large service providers
    • It inhibits transparency
    • It is inaccurate
    • It ignores outcomes


Chapter 14 – Turn IT into a competitive advantage

This chapter is discussed some strategies to increase the responsiveness of IT to changing business needs, improve the stability of IT services, and reduce the complexity of our IT systems and infrastructure.

Rethinking the IT Mindset: IT has historically been seen as a cost center and an internal enabler of the business, not a creator of competitive advantage. In the 2014 State of DevOps Report, over 9,000 people worldwide were polled about what creates high-performance organizations, whether IT does in fact matter to the business, and what factors impact the performance of IT departments.

rethinking it mindsetWhat business leaders think about the business-IT relationship

The practices most highly correlated with high IT performance (increasing both throughput and stability) are:

  • Keeping systems configuration, application configuration, and application code in version control
  • Logging and monitoring systems that produce failure alerts
  • Developers breaking up large features into small, incremental changes that area merged into trunk daily
  • Developers and operations regularly achieving win/win outcomes when they interact

If we want to compete in a world of ever shorter product cycles, central IT needs to be business unit’s trusted partner, not an order-taking cost center. In turn, IT needs to achieve higher levels of throughput while improving stability and quality and reducing costs. The complexity of existing enterprise IT environments, combined with the amount of planned and unplanned work that must be done to keep them running, are the chief barriers to achieving these outcomes.

Chapter 15 – Start where you are

The biggest barrier to success in changing the way you work is a conviction that your organization is too big or bureaucratic to change, or that your special context prevents adopting the particular practices we discuss. Always remember that each person, team, and business that started this journey was unsure of what paths to take and how it would end. The only accepted truth was that if they failed to take action, a more certain, negative ending lay ahead.

The only path to a culture of continuous improvement is to create an environment where learning new skills and getting better at what we do is considered valuable in its own right and is supported by management and leadership, thus reducing learning anxiety. We can use the Improvement kata (presented in chapter 6) to create this culture and drive continuous improvement.

pdcaContinuous evolution and adaption to change

The process of creating alignment and consensus between levels is critical. In strategy deployment, this process is described as catchball, a word chosen to evoke a collaborative exercise. The target conditions from one level should not be transcribed directly into the direction for teams working at the level below. Catchball is more about translation of strategy, with “each layer interpreting and translating what objectives from the level above mean for it”.

Using catchball to drive strategic alignment of objectives and initiatives

Begin your journey: use the following principles for getting started:

  • Ensure you have a clearly defined direction
  • Define and limit your initial scope
  • Pursue a high-performance culture of continuous improvement
  • Start with the right people
  • Find a way to deliver valuable, measurable results from early on

Creating a resilient, lean enterprise that can adapt rapidly to changing conditions relies on a culture of learning through experimentation. For this culture to thrive, the whole organization must be aware of its purpose and work continuously to understand the current conditions, set short-term target conditions, and enable people to experiment to achieve them.

We then reassess our current conditions, update our target conditions based on what we learned, and keep going. This behavior must become habitual and pervasive. That is how we create a mindset of continuous improvement focused on ever higher levels of customer service and quality at ever lower costs.

The Testing Manifesto e testes automatizados

Assim como o Manifesto Ágil que declara valores e princípios essenciais para o desenvolvimento de aplicações e o ciclo de vida ágil, The Testing Manifesto é o manifesto voltado a práticas de testes durante o ciclo de vida, propondo alguns valores a todo o time (e não somente a testers):

  • Testing throughout OVER testing at the end: o retrabalho aumenta exponencialmente quando tentamos corrigir bugs posteriormente em qualquer ciclo de vida. É por isso que testamos desde o início e frequentemente.
  • Preventing bugs OVER finding bugs: “built-in quality”. O foco é criar aplicações com qualidade desde o início, pensando no sistema em produção e manutenção.
  • Testing understanding OVER checking functionality: o senso de propriedade compartilhada resulta em maior qualidade. Precisamos checar o entendimento do time no que está sendo construído. O pair programming, code reviews, entre outros, podem ajudar a coletar feedbacks.
  • Building the system OVER breaking the system: o “built-in quality” é uma abordagem proativa e através de CI/CD, testes automatizados, monitoramento inteligente, etc. tornamos a qualidade integrada mais alcançável.
  • Team responsibility for quality OVER tester responsibility: o time é responsável pela qualidade do produto que está sendo criado.


A cultura de testes é imprescindível para o time para alcançar a qualidade integrada. Além das práticas de desenvolvimento orientado a testes (que será abordado mais adiante neste artigo), algumas intersecções entre o The Testing Manifesto e o ciclo de vida ágil podem ser observados:

  • Iterative cycles and incremental: os times trabalham com ciclos iterativos e incrementais, o que previne testar o sistema somente no fim e consequentemente encontrar os bugs na fase final.
  • Testing in all development process: desde a criação de um Work Item (descrevendo os planos de testes associados e critérios de aceitação), as práticas de desenvolvimento orientado a testes (TDD), entre outros, garantem o time em alinhamento com o que está sendo construído desde o início.
  • Cross functional teams / Squads: a responsabilidade é de todos pela qualidade e não somente QA.


Agile Testing Quadrants

O Agile Testing Quadrants exibe a visão em quatro quadrantes dos testes durante todo o ciclo de desenvolvimento. Enquanto os dois quadrantes abaixo são relacionados a technology facing por não ter interação com o usuário (interface), os dois quadrantes acima são business facing, pois há interação do usuário. Também há a representação de cada quadrante se os testes são manuais, automáticos ou ferramentas.

  • Quadrante 1 (Q1): TDD (Test Driven Development) é a principal técnica. Não é visível aos usuários. Geralmente está no processo de CI (Continuous Integration). Também inclui qualidade de código (SonarQube, etc.)
  • Quadrante 2 (Q2): BDD (Behavior Driven Development) é a principal técnica. Está mais relacionado a qualidade externa da aplicação e está visível aos usuários. Também inclui testes funcionais automatizados (serviços, API e webservices) e record playback.
  • Quadrante 3 (Q3): assegura que as necessidades do usuário foram atingidas, por exemplo com UAT (user acceptance testing), testes exploratório e de usabilidade. O usuário é envolvido na execução.
  • Quadrante 4 (Q4): avaliação técnica. Sugere a execução dos testes de segurança, carga e performance.


Symbio Test Automation

Na comparação entre o ciclo tradicional (find bugs) e ágil (prevent bugs), podemos ver que enquanto os testes unitários representam a maior parte do esforço em ciclos ágeis, os testes manuais em UI (User Interface) compreendem o maior esforço em ciclos tradicionais. Segundo o Symbio Test Automation, cerca de 70% dos testes são unitários, 20% correspondem a testes de API, Integrações e Componente, e por fim 10% são dedicados a testes GUI (graphical user interface).



Vemos no quadro abaixo uma comparação bem resumida de TDD – prática de escrever os testes antes do desenvolvimento e BDD que especifica os cenários de funcionamento para a aplicação e os testes são desenvolvidos com base nesses cenários.

TDD (Test Driven Development)

  • Tests are written before the code
  • Improve code design
  • Created to work with unit test
  • Executed in CI process
  • Facilitates regression
  • Refactoring mitigates risk
  • Red – Green – Refactor


BDD (Behavior Driven Development)

  • TDD Derivation
  • Support the questions: Where to start? What to test and what not to test? What to test at each step? Helps understanding why a test fails
  • Ubiquitous language and live documentation.  Understanding the requirements



1. Escrevemos um Teste que inicialmente não passa (Red)
2. Adicionamos uma nova funcionalidade do sistema
3. Fazemos o Teste passar (Green)
4. Refatoramos o código da nova funcionalidade (Refactoring)
5. Escrevemos o próximo Teste


Após toda a explicação teórica (acima) e compreensão da aplicabilidade dos testes durante o ciclo de vida do desenvolvimento, vale discutir com sua equipe o planejamento das ferramentas que serão utilizadas na organização. Abaixo, compartilho uma visão de onde pode ser utilizada cada tipo de ferramenta:



E por fim, como podemos acompanhar o resultado dos testes durante as iterações? Veja que o Dashboard abaixo apresenta alguns KPIs como code coverage (cobertura de teste unitário na aplicação) e test results (em relação aos planos de teste).

Como explicado na figura dos quadrantes (acima neste post), os testes devem ocorrer desde o início do ciclo de vida, por exemplo, criando e validando os testes unitários no processo de CI. As releases podem ser validadas pelos usuários após serem promovidas (a um ambiente de homolog por exemplo). A execução dos testes de segurança, carga e performance acontecem por sugestão no ambiente de QA.


DevOps e ligação com Scrum e SAFe

Neste post você encontra um resumo da ligação do DevOps com outras práticas, tais como: Scrum, SAFe, Extreme Programming (XP), Lean, Kaizen, Kanban, ITIL e Infrastructure as code.

Manifesto Ágil

O manifesto ágil não inclui entre os doze princípios a colaboração de Ops. O The Agile Admin entende ser em função do tempo, pois há dez anos atrás, a maioria das aplicações eram desktop. Também não menciona nada sobre a última parte do pipeline de entrega de software (onde as aplicações são publicadas e mantidas em produção).

manifesto-agilE assim, foi criado o Manifesto DevOps por Jez Humble:manifesto-agil-principios-01manifesto-agil-principios-02

Agile addresses perfectly customer’s needs

  • Visibility: visibilidade e transparência durante todo o ciclo.
  • Adaptability: planejamento iterativo torna fácil a adaptação em caso de mudança de requisitos.

  • Business Value: o planejamento e feedback contínuo trazem entrega de valor desde o início do projeto.
  • Risk: e assim diminuem os riscos associados ao desenvolvimento.


Os dois princípios derivados:

1. Automatize quase tudo

  • Processo de Build até o ponto onde é necessário intervenção humana
  • Processo de deployment
  • Testes de aceitação
  • Upgrades and downgrades de base de dados
  • Infra estrutura e até mesmo configurações de rede e firewall

2. Mantenha tudo que for necessário para o build, deploy, testes e release em seu controle de versão.

Create a Repeatable, Reliable Process for Releasing Software

releasing software should be easy (as simple as pressing a button), because you’ve tested every single part of the release process many times before”.



É um framework para desenvolver, entregar e manter produtos complexos. Consiste de times Scrum associados a papéis, eventos, artefatos e regras. Os três pilares são transparência, inspeção e adaptação. E os cinco valores são comprometimento, coragem, foco, transparência e respeito.


  • Time Scrum:  auto organizáveis e multifuncionais. É composto do Product Owner, Time de Desenvolvimento e Scrum Master.
  • Eventos: todos os eventos são time-boxed. São eles: Sprint, Planning, Daily, Review e Retrospective.
  • Artefatos: Backlog do Produto, Backlog da Sprint e Incremento.

As práticas como burn-downs, burn-ups, ou fluxos cumulativos são utilizadas para prever o progresso.

Take an economic view: increase value
O Scrum emprega uma abordagem incremental e iterativa, maximizando as oportunidades para feedback e previsibilidade. Ao final de cada Sprint, o time de desenvolvimento entrega um incremento potencialmente liberável do produto “Pronto”.


Os built-in controls minimizam o risco de produzir desperdício e falta de progresso:

  • Eventos
  • Inspeções
  • Guardião Scrum (Scrum Master)
  • DoD (definition of done)

Entre os benefícios estão:

  • Maior frequência de entregas de valor
  • Maior visibilidade nas tarefas que estão sendo concluídas
  • Maior capacidade de adaptação às mudanças
  • Maior alinhamento com prioridades do negócio (tanto no planejamento quanto na execução)
  • Maior foco na qualidade por time box
  • Maior previsibilidade em time boxes menores
  • Maior compreensão dos riscos, incertezas e impedimentos
  • Maior foco na redução de desperdícios

SAFe (Scaled Agile Framework)

SAFe é um framework para trabalhar com ágil em larga escala que sincroniza alinhamento, colaboração e entrega para grande número de times. Também reflete em pensamento Lean-Agile e práticas DevOps. Os valores fundamentais são:

  1. Built-in Quality: “you can’t scale crappy code”
  2. Program Execution: product portfolio
  3. Alignment
  4. Transparency


SAFe principles:

#1 – Take an economic view
#2 – Apply systems thinking
#3 – Assume variability; preserve options
#4 – Build incrementally with fast, integrated learning cycles
#5 – Base milestones on objective evaluation of working systems
#6 – Visualize and limit WIP, reduce batch sizes, and manage queue lengths
#7 – Apply cadence, synchronize with cross-domain planning
#8 – Unlock the intrinsic motivation of knowledge worker
#9 – Decentralize decision-making

Definição de pronto – DoD (Definition of done)

Neste post vamos falar sobre a Definição de pronto, também conhecida como DoD (Definition of Done). Ao adotarmos métodos ágeis, este é um conceito-chave, pois ao final de cada iteração, um incremento de produto deve estar pronto pelo time. No Scrum, por exemplo, o pilar de transparência*, menciona que “aqueles que realizam o trabalho e aqueles que inspecionam o incremento resultado do trabalho devem compartilhar uma definição comum de Pronto”.

* os três pilares que apoiam a implementação de controle de processo empírico: transparência, inspeção e adaptação


Definição de pronto
O Scrum então resume os principais aspectos a serem considerados na DoD:

  • Quando um item do Backlog do Produto ou um incremento é descrito como “Pronto”, todos devem entender o que o “Pronto” significa, pois será usado pelo time para assegurar quando o trabalho está completado no incremento do produto.
  • Ela orienta o time de desenvolvimento no conhecimento de quantos itens do Backlog do Produto podem ser selecionados durante o Planejamento da Sprint.
  • Como o time de desenvolvimento entrega um incremento de funcionalidade do produto a cada Sprint. Este incremento é utilizável, então o Product Owner pode escolher por liberá-lo imediatamente.
  • Se há múltiplos Times Scrum trabalhando no sistema ou versão do produto, os Times de Desenvolvimento de todos os Times Scrum devem mutuamente definir uma definição de “Pronto”.
  • Cada incremento é adicionado a todos os incrementos anteriores e completamente testado, garantindo que todos os incrementos funcionam juntos.

Considerando todos os itens mencionados acima, o desenho abaixo representa um resumo para a definição de pronto :


E alguns exemplos utilizando a Definição de Pronto:


Por fim, a Definição de Pronto traz benefícios ao seu ambiente de trabalho por aumentar a transparência previsibilidade dos incrementos. Entre os principais, podemos destacar:

  • Todos interessados sabem exatamente o que significa um produto pronto
  • As entregas passam a ser mais previsíveis
  • Serve como um acordo entre o PO e time desenvolvimento
  • Ajuda a assegurar que o incremento esteja em condições de ser liberado para produção ao final da iteração
  • Ajuda o time no planejamento da sprint


O Mapa de histórias (story mapping) e Roadmap de produto

Neste post, vamos abordar a criação do Roadmap de produto e Mapa de histórias (story mapping). Antes, contextualizo alguns conceitos importantes a serem considerados na fase inicial de projetos ágeis, tais como: ciclo de projetos ágeis (fase de viabilidade e iniciação), gerenciamento orientado a valor e estimativas.

John Decoster

Já vimos anteriormente sobre a abordagem de ciclo de projetos ágeis, recomendada em cenários de incertezas com relação aos requisitos, recursos e tecnologia. 

estratégia de entregas iterativas, curtas e incrementais, combinada com ciclos adaptativos, permitem mudanças ao planejamento e mitiga os riscos derivados do cenário complexo, apresentado na imagem ao lado.

Neste contexto, o gerenciamento orientado a valor permeia todo o ciclo e maximiza o valor de cada entrega dos times ágeis de forma antecipada. Na fase de viabilidade e iniciação (PMI ACP por Mike Griffiths) do projeto, recomenda-se deixar claro o objetivo geral do projeto e propósito do produto:

  • Business case: mesmo em projetos ágeis, cálculos de ROI, VPL e TIR ajudam a dirigir por valor de negócio.
  • Termo de abertura ágil: descreve em alto nível o objetivo do projeto, a proposta, o escopo e a abordagem.
  • Backlog inicial do produto: representa a visão do produto e evolui conforme o produto vai sendo utilizado pelos usuários. Geralmente, são escritos em user stories. A técnica de Lean Inception pode contribuir nesta elaboração.

Estimativas iniciais
cone da incerteza reflete que na fase inicial do produto, período de maiores incertezas, as estimativas são menos precisas. Por isso, em gestão ágil, tratamos as estimativas de forma cíclica, conforme há maior detalhamento.


Entre os tipos de estimativas, devemos considerar as funcionalidades desejadas, a complexidade e o esforço.

  • Estimativa de complexidade: utiliza pontos de complexidade para dimensionar o tamanho das user stories. A partir do tamanho de uma história (mais conhecida), utiliza-se valores relativos para comparar com as demais. Exemplo: determinado que a história “consultar cliente” possui 1 ponto, a história “cadastrar cliente” possui o dobro do tamanho?
  • Estimativa por afinidade: agrupa itens em categorias similares. Esta triangulação oferece uma visão comparativa das estimativas. É aplicável quando há um grande número de histórias para serem estimadas.

Roadmap de produto
O Roadmap de produto é um artefato que combina os objetivos do negócio, as necessidades do cliente e as tarefas necessárias para atingir esses objetivos. É com ele que planejamos e  comunicamos a visão de futuro do produto aos interessados.

O objetivo é alinhar diferentes visões, organizando as ideias de desenvolvimento do produto, definindo prioridades e agregando o máximo de valor ao seu negócio. Auxilia em questionamentos da evolução do produto “onde estamos?”, “ onde queremos chegar?” e “como chegaremos?” e outros aspectos:

  • Visibilidade do desenvolvimento e liberação de produtos
  • Facilita a comunicação dos interessados em relação a priorização e disponibilidade de novas funcionalidades


Mapa de histórias (story mapping)
User Story Mapping é um mapa que organiza as histórias de usuário em um modelo que ajuda a compreender a funcionalidade do sistema, a identificar falhas no seu backlog, e a, efetivamente, planejar releases holísticas que oferecem valor aos usuários e ao negócio a cada versão”. Jeff Patton – The New User Story Backlog Is a Map.

É a big picture utilizada pelos times ágeis quando precisam visualizar roadmaps de produtos de alto nível e planos de releases. Expõe uma visão da forma como o trabalho vai ser desdobrado em três elementos:

  • Backbone (user activities): os temas que o usuário será capaz de executar com o fluxo de trabalho.
  • Walking skeleton (user tasks): são as tarefas que suportam o backbone. 
  • Histórias de usuário: representa a quebra das histórias que permitem a conclusão das tarefas.


Veja agora em um exemplo prático do blog how to prioritize a User Story Map. Podemos ver a USM (User Story Mapping) e o passo a passo mapeado para histórias e releases.



CertiProf – Resumo das certificações Scrum (SFPC) e DevOps (DEPC)

Neste post vou compartilhar algumas dicas para quem deseja realizar os testes de certificação da Certiprof. A empresa liberou por tempo indeterminado o acesso gratuito a estes dois exames online:

1. Scrum Foundation Professional Certificate (SFPC)

O guia de preparação é dividido em 4 partes:

  • Parte 1: introdução dos conceitos de Ágil, Manifesto Ágil, tipos de projeto e Scrum.
  • Parte 2: teoria do Scrum – três pilares (transparência, inspeção e adaptação), valores e essência do Scrum.
  • Parte 3: papéis e responsabilidades dos times.
  • Parte 4: principais conceitos – user story, time-boxing, sprint, eventos e artefatos.

Realize os simulados antes de fazer o teste de certificação. A prova é bem simples para quem já conhece o Scrum Guide e os conceitos de agilidade. Uma revisão no guia de preparação também é recomendado.

2. DevOps Essentials Professional Certificate (DEPC)

O guia de preparação é dividido da seguinte forma:

  • Introdução: conceitos, história, objetivo, benefícios e pilares do DevOps.
  • Conceitos: princípios, papéis e responsabilidades, desafios organizacionais, gerenciamento de configuração, Entrega contínua e Integração contínua.
  • DevOps e outras práticas recomendadas: Agile, Scrum e ITSM (ITIL).
  • Culturas DevOps e Adoção incremental de DevOps
  • Ferramentas DevOps: Eclipse, JIRA, Maven/Ant, Git/GitHub, Chef, Docker, Puppet, Jenkins/Bamboo, Nexus/Artifactory, New Relic, Splunk, Nagios, etc.
  • Modelo Gartner DevOps: pessoas, processos, tecnologia e cultura
  • Modelo de maturidade e autoavaliação