Then, suddenly, the P.O. discovers that the features D and E were developed by a competitor and that you are losing users because of that. Therefore, the P.O. decides to deprioritize story C. This is only an example of why a card might be deprioritized in the middle of its development. But now that it was deprioritized, what happens to story C?

Well, to answer that, let me make a parallel with an alcohol-based perfume company.

In the backlog column, the company has the bottle ready to be filled but no fluid yet. When the bottle starts to be filled, the card goes to “in progress”. When the bottle is totally filled, the bottle is closed and the card goes to done.

So what happens if another perfume suddenly receives a priority greater than the priority of the bottle being filled? Well, as we all know, alcohol-based fluids are volatile and, with time, they will completely evaporate, requiring them to be refilled.

The same happens with the story and its code. With time, the code that is inside the story gets obsolete and unnecessary, losing its value. What to do with the story depends on the following rationales:

• How long will the story C stay in the same stage?
  • If the story stays too long in the same stage, some part of the work may get useless, therefore, you could just remove it from the board and put it back on backlog, since some refining might be needed when this story is chosen gain.
  • If the story will stay there for a short time, you may want to leave it there and, when it can be worked on, you may still use what was already developed.
• What is the value story C will generate after being done?
  Let’s say that the return on the development of that feature is small. Is it worth to pause its development and run the risk of investing even more money on the development later? Will the return on its development be greater than the development time?

For this to be true, the following needs to happen (visualized in the chart below):

• $ spent with initial development + $ spent with rest of the development < story C $ return
  • The amount spent with rest of the development will increase with time, since the initial development starts to lose value.
• If the amount spent is greater than the return, it is better to ignore the functionality. However, this math is not as easy as it seems… You need to account for risks, increased revenue, increase the number of users of your product, etc. So be careful!

Therefore, based on those, you can possibly do four things:

• Leave it on the column and restart it when its priority arrives
  The pause will be fast and will not harm the development of the card. In this case, it is important to flag the story somehow so that the whole team can see that the story is “blocked” by the P.O. due to its prioritization.

• Take it back to the backlog, and restart it when its priority arrives
  The pause will be long and the card will need more refinement.

• Finish it first, before getting another card
  The card is almost done, and if you stop it, it will not generate value anymore.

• Cancel the card
  The card is a long way from being finished, and its value is too small to pay for the time it will be paused.

It is also important to notice that this should NOT be a common thing in your process. If it is happening too often, you may need to work on your prioritizations!

What are your thoughts on the topic? Leave your comments below

The post The user story in development was deprioritized, what now? first appeared on Plataformatec Blog.

Então, no meio do seu sprint, o P.O. descobre que as features D e E foram lançadas por um concorrente e que vocês estão perdendo usuários por isso. Pensando nisso, a P.O. decide despriorizar a história C. Isso seria apenas um exemplo de como um card pode ser despriorizado no meio do seu desenvolvimento. Mas, e agora, o que acontece com a história C?

Para responder isso, deixe-me fazer um paralelo com uma companhia de perfumes a base de álcool.

Na coluna de backlog, a companhia tem a garrafa pronta mas sem fluído algum. Quando a garrafa começa a ser enchida, o card é passado para “in progress”. Após a garrafa estar cheia, ela é lacrada e o card vai para “done”.

O que acontece então se outro perfume tem sua prioridade elevada a um nível maior do que o que está sendo abastecido? Bom, como sabemos, fluídos com base em álcool são voláteis e, com o tempo, evamporam totalmente, sendo necessário que se reabasteça o recipiente.

O mesmo acontece com uma história e seu código. Com o tempo, o código que compõe tal história se torna obsoleto e desnecessário, perdendo o valor que tinha outrora. Neste caso, o que fazer com a história despriorizada depende dos seguintes pontos:

• Quanto tempo a história C continuará no mesmo estágio?
  • Se a história permanece muito tempo no mesmo estágio, alguma parte do trabalho já feito pode se tornar desnecessário, portanto, você poderia apenas removê-la da coluna e colocá-la de volta ao backlog, já que algum refinamento pode ser necessário para que essa história seja desenvolvida novamente.
  • Se a história vai ficar por um curto período de tempo em tal coluna, você pode optar por deixá-la lá e, quando sua hora chegar, pode continuar aproveitando o que já havia sido desenvolvido.
• Qual o valor que a história C vai gerar quando pronta?
  Digamos que o retorno gerado pelo desenvolvimento de tal feature seja pequeno. Será que vale a pena pausar seu desenvolvimento e ter o risco de investir ainda mais dinheiro no seu desenvolvimento em outro momento? O retorno gerado será maior do que o tempo total de desenvolvimento gasto?

Para que isso seja verdade, o seguinte precisa acontecer (observado na imagem abaixo):

• $ gasto com o desenvolvimento inicial + $ gasto com o resto do desenvolvimento < retorno da história C
  • A quantia gasta com o resto do desenvolvimento aumentará com o tempo, já que o desenvolvimento feito anteriormente vai perdendo valor.
• Caso o retorno seja menor do que o gasto, é melhor ignorar a funcionalidade. No entanto estes cálculos não são tão simples como parecem… Você precisa levar em conta riscos, aumento na receita, aumento no número de usuários, etc… Então tenha cuidado com essa ação.

Portanto, baseado no que já foi dito, você pode ter as seguintes ações a respeito do card C:

• Mantenha-o na coluna “in progress” e recomece o trabalho quando sua prioridade for retomada
  Essa pausa será rápida e não afetará o desenvolvimento da feature. Neste caso é importante deixar visível de alguma forma no quadro que essa história está “bloqueada” por motivos de priorização.

• Ponha-o na coluna de backlog novamente, e recomece quando necessário
  A pausa será longa e o card precisará de um novo refinamento.

• Termine-o primeiro, antes de começar outra história
  O card está quase pronto e, caso você pare seu desenvolvimento, quando pronto, seu valor será menor do que o gasto no seu desenvolvimento.

• Cancele o seu desenvolvimento
  A história está muito longe de ser terminada, e seu valor final é muito pequeno para pagar o tempo que ela ficará pausada.

É importante também notar que isso NÃO deve ser algo comum em seu processo. Se coisas como essa estão acontecendo frequentemente, você pode precisar melhorar suas priorizações!

O que acha do que foi discutido aqui? Deixe seus comentários abaixo!

The post A user story em desenvolvimento foi despriorizada, e agora? first appeared on Plataformatec Blog.

• Como priorizá-las?
• Quando elas serão entregues?

Neste blog post, teremos a oportunidade de discutir algumas abordagens que poderão ajudar você a responder tais questionamentos (neste ano, falarei mais sobre o assunto aqui no blog).

Tenho observado um movimento de gestão de produtos que vem concretizando os princípios por trás do Lean Startup que diziam: construa, meça e aprenda. A partir da ótica de medir e aprender, é perceptível que gestoras e gestores de produto começam a levantar hipóteses de negócio a partir de métricas como taxa de conversão, recorrência mensal, taxa de evasão, análise da interação dos usuários nos fluxos críticos da aplicação, etc.

Voltando para a primeira pergunta que abriu o texto, nos deparamos com atributos quantitativos que nos permitem priorizar o que precisamos construir. Tal ferramental sustenta a ideia de que estamos interessados em melhorar os resultados do produto a partir de números.

Antes que alguém me crucifique, nem só baseados em números devem ser os fatores para a priorização de novas features dos produtos que trabalhamos. Caso você tenha a possibilidade de se aproximar do seu usuário para perguntá-lo o que ele deseja, você também estará aumentando a probabilidade de construir algo que traga valor para ele. Dados qualitativos podem ser coletados através de questionários online, pesquisas de campo, análises de interação a partir de protótipos, etc.

Ao priorizarmos uma funcionalidade, estamos em busca de gerarmos uma solução que traga valor para nossos usuários, clientes, acionistas e empresa. Em outras palavras, podemos dizer que estamos em busca de encontrarmos uma relação positiva na equação de valor que nada mais é do que a diferença entre o valor criado pela solução menos o preço pago por ela #maisvalorporfavor.

Quadro de abordagens quali e quantitativa

Dado que priorizamos aquilo que é mais importante para a saúde do produto e para os usuários, um segundo questionamento que por vezes fica na cabeça é: quanto tempo levaremos para entregar essa nova feature?

Partindo do pressuposto que vivemos em um contexto incerto (sim, acredite, desenvolver software não é algo determinístico), trabalhar com cenários de entrega passa a ser uma abordagem mais confiável. Ao utilizar projeções você passa a calcular ou predizer um evento futuro a partir da análise dos dados disponíveis (passado).

Para que isso seja possível, sugiro que você e a sua equipe passem a monitorar uma métrica de processo: lead time (número de dias entre o início e o fim do processo de entrega de uma história do usuário, um bug, etc.).

Em outras oportunidades tivemos a chance de discutir formas de analisar o lead time (“Looking at Lead Time in a different way” e “Why we love metrics? Learning with Lead time”), porém, gostaria de compartilhar como o percentil pode ser uma referência útil para desenhar cenários futuros a partir de referências do passado.

Se você não conhece, percentil é uma medida que divide a amostra ordenada (por ordem crescente dos dados) em 100 partes, cada uma com uma percentagem de dados aproximadamente igual. Traduzindo e relacionando com uma distribuição de lead time, é como se analisássemos o lead time das demandas que foram entregues e discutíssemos qual o percentual de chances de um determinado valor ser atingido a partir do percentil.

Em um projeto recente utilizamos a informação de percentil para projetar possíveis prazos de entrega de uma demanda de negócio que havia sido priorizada pelo Product Owner (PO) da célula em que trabalhamos.

Histograma de lead time

A equipe utilizou o histograma acima e passou a seguinte análise do cenário ao PO:

• 50% das demandas levaram até 6 dias para serem concluídas (mediana).
• 75% das demandas levaram até 12 dias para serem concluídas ou seja apenas 25% levaram mais do que tal limite para serem concluídas (percentil 75).
• 95% das demandas levaram até 18 dias para serem concluídas, o que nos leva a afirmar que apenas 5% delas levaram mais tempo do que isso para serem finalizadas (percentil 95).

A partir dos dados acima, o time demonstrou confiança de entregar a demanda entre 6 e 12 dias. Com tal informação em mãos, o PO traçou o plano de comunicação e promoção do novo recurso do produto. Se você ficou curioso em saber, a demanda foi entregue em 8 dias.

Ao utilizar tal abordagem de projeção, o time e o PO se sentiram mais confortáveis e confiantes. Caso o PO tivesse imposto para o time que a nova demanda deveria ser entregue em 3 dias, com posse das informações de percentil, o time teria insumos para dizer que seria muito difícil entregá-la pelo simples fato de que apenas 25% das demandas entregues foram concluídas no prazo determinado (percentil 25).

Fecho esse texto com algumas sugestões:

1. Crie hipóteses através de fatos que podem ser originados por dados quanti ou qualitativos.
2. Projete cenários de entrega a partir de uma referência (histórico do time).
3. Desenvolva pequenas entregas de valor, pois elas permitirão que você mude de direção mais rápido.
4. Não acredite que métrica de produto ou processo é algo burocrático, pois elas servem como uma base para você construir um futuro melhor.

E você? Como tem priorizado e projetado suas entregas? Quais métricas e abordagens tem utilizado? Compartilhe sua opinião nos comentários abaixo. Estou curioso para aprender com o seu exemplo.

Se está interessado saber mais como lidar com prazos de projetos de software não deixe de conferir nosso e-book gratuito sobre o assunto.

The post Dilemas de PO: priorizar features e projetar entregas first appeared on Plataformatec Blog.

As well as a big software refactor, a rewrite is not a simple thing either. After many years, we have gotten experience enough to point what you had better consider when planning and executing a rewrite process.

Will the two platforms live together for some time or not?

Are you planning to maintain the legacy and the new version in production? If so, for how long? You should avoid maintaining two versions in production for too long because of opportunity and operating costs.

Who will work on the rewrite and who will work on the legacy version?

Developers usually prefer to work on green field projects. You should take that into account when planning who will maintain the legacy version and who will work on the new one.

It’s not viable to rewrite every single feature at once

It’s not viable to have a 1 to 1 feature mapping between the legacy version and the new one. That said, what features should you start rewriting?

Take into account how current clients will be impacted by a product with fewer features.

A rewrite will slow down or stop the launch of new features in the legacy version

Chances are you won’t launch new features for the legacy version during the rewrite process. Not only will end-users not get new features, but neither will internal clients (commercial and product departments). Your internal clients and stakeholders will pressure you to deliver new features.

Make sure that the communication before and during the rewrite is clear, and that every stakeholder is aligned with the end goals.

Keep it secret or public?

Imagine you are a potential customer of a software product. You’re planning to buy it, but you just found out that a completely new version will be launched in three months. Would you buy the legacy version or wait for three months? Multiply that by dozens or hundreds of potential buyers. The provider could lose a lot of money.

That’s why if you’re the provider, you should think carefully about how and when you’re going to publicize the launch of a brand new version.

Data migration

A rewrite process is not just shipping features. You also need to plan the data migration. People usually underestimate the complexity and effort needed to migrate data from the legacy version to the new version. That activity should not be just one task on your board called “data migration.”

For example, imagine that you need to migrate your users’ accounts. If your legacy version is managed by a third-party, chances are you won’t have access to the users’ encrypted passwords, so you won’t be able to migrate them. You’ll have to ask every single user to reset their passwords in the new version. That’s part of the data migration process, too.

Prepare for a possible decrease in conversion rates

You’ll launch a new version with fewer features. Who guarantees that the conversion rates will stay the same? Conversion rates are vital in some domains, like in e-commerce.

Ideally, you should be able to keep both the legacy and the new version running for a while so that you have a backup plan in case there’s a huge decrease in conversion rates.

Plan time to train internal users

This is another overlooked subject. The rewrite plan needs to have a phase of internal user training before taking your new product to production. Don’t underestimate that, either. It can take a long time since your internal users will give you feedback about stuff that might need to be changed.

Internal users can be found in a variety of areas, such as help desk and inside sales.

What about you? Do you have any more tips on what to worry about when doing a rewrite? Share with us!

The post Key points to consider when doing a software rewrite first appeared on Plataformatec Blog.

Doing a big software refactor¹ is not a simple thing. There are lots of points that you should think about, from planning and prioritizing to team motivation and execution. Understanding these points in a structured and clear way is part of the job. The good news is that we’ve been in that situation before and have learned the key points you should worry about.

Here are the main points you should consider when planning and executing a big refactoring process.

Define your business goals

A big software refactoring process should not be started without clear business goals, otherwise it can suffer from a lack of commitment by your stakeholders. Here are some examples of goals:

• We’re doing a refactor so that we can plug in multiple payment gateways.
• We’re doing a refactor so that we can improve velocity.
• We’re doing a refactor so that we can have a multi-tenant architecture in order to simplify our infrastructure operations.

Measure progress

By its very nature, a software refactoring process is a technical effort, which is why it’s common for people not to measure its progress in the same structured way that they measure progress on development of new features. Don’t fall into that trap.

As with every task in a project, a refactor should always be planned and measured.

Pay attention to your team’s motivation

Working on a legacy codebase can be demotivating for developers, especially if they don’t have a feeling of progress, or if they don’t know when it’s going to end. When going with a refactoring process, you should keep this in mind.

Show your team they’re moving forward. Plan for small deliverables, so that you can continually ship stuff and celebrate the good work done. Also, think about developer rotation, which can help by maintaining motivation and keeping fresh eyes on the task.

Define your approach: pull or push?

Are you going to improve your codebase only when touching some bad part of it, or are you going to proactively choose which parts you’re going to improve?

Prioritizing

If you have a clear business goal, it’s easier to proactively choose which parts need to be improved to make that goal a reality. With the parts listed, you can apply your usual prioritization techniques.

But if you’re going to do a constant and big software refactor because you know the whole codebase needs to be improved, it’s more difficult to prioritize. This is because there are not just one or two main parts that need improvement, but lots of them. It’s difficult to know where to start.

One way to prioritize in that situation is to instruct your team to evaluate which parts need to be refactored based on their complexity and churn. By that we mean, whenever they are evaluating if some part of the code should or should not be refactored, they should ask themselves:

• “Is the complexity of that class too high compared to the others?”
• “Do we constantly need to make changes on that file?”

If the answers are both yes, that part is a good candidate for refactoring. Plot a chart of “class complexity X churn” and prioritize the parts that are too complex and that you’re changing every time.

The parts that have big complexity but don’t need to change constantly are not good candidates to be refactored because they’re parts that are ugly but usually work, and nobody needs to change them to do their everyday job.

Know when you’re done

A software refactoring process can turn into an endless endeavor if you don’t plan, prioritize and measure progress. You should treat it as a project. It should have a beginning, a middle and an end.

Test suite coverage

Your refactoring process should improve stuff that is already working without breaking anything. Make sure you have good test coverage, otherwise the process can generate more bugs than quality improvements.

Test suite performance

If your test suite is too slow, it will slow down the refactoring process since a software refactor is greatly based on continuously running the tests. Make sure the test suite performance is not a bottleneck.

Sponsors commitment

A refactoring process can take a long time: weeks, months. During that time the velocity in which new features are delivered will be compromised. Make sure that every business stakeholder understands the goals and the nature of that kind of work, so that they don’t give up in the middle of it.

What about you? Do you have any more tips on what to worry about when doing a big software refactor? Share with us!

The post Key points to consider when doing a big software refactoring first appeared on Plataformatec Blog.

Not only physical matter deteriorates, software does too

It’s known that physical matter deteriorates. People accept that and have always dealt with it. What people don’t accept so easily is that software “deteriorates” too. Unlike physical matter, it doesn’t happen due to some physical or chemical phenomenon. It usually happens because of some business change or people change. Let me give you an example.

Imagine you’re leading the tech or product team of a startup; you’re the CTO. You already launched your product’s first version, and it was a success. Your business model was validated, and now you’re in a growth stage. That’s awesome! But it has its costs, and it brings a new set of challenges.

The first version of your product is working, but the codebase is not in the shape you’ll need from now on. Maybe your team’s velocity is not as good as it used be. Your team keeps complaining about the code quality. The CEO and the product director want new features, and your current projections will not meet the business needs.

It’s not uncommon that one of the main sources of all these problems is the poor quality of your product’s codebase. You may need a refactoring ¹ or a rewrite.

When the codebase is not in good shape, everyone can get frustrated

If the internal quality of your product is not good, everyone becomes frustrated.

Your whole team, including developers, will get frustrated because they would like to ship features faster, but the current code quality and architecture are not helping.

The IT, product, and software departments suffer because they’re not able to meet the expectations of the other departments.

The customer also suffers because of frequent bugs, how long it takes for them to be resolved, and how long it takes new features to be launched.

You get the picture.

Identifying the symptoms

It’s the leader’s job (let’s say the CTO) to identify when a refactor or a rewrite is needed. In order to do that, he or she can look around for some symptoms, like the ones below:

• Everything is hard: Almost every feature or bug fix your team needs to do is hard. It was not always like that. You remember the good old days when your team was fast and everything ran smoothly.
• Slow velocity: Your team’s velocity decreased or is decreasing. When you were building the first version of your product, it was fast to develop a new feature, and your team used to build lots of them every iteration. Now it’s different.
• Slow test suite: Your test suite takes 10x, 20x, 30x more time to run than before.
• Bugs that don’t go away: Your team fixes a bug, then in a week or so it appears again. Every now and then your team is fixing a regression bug.
• Your team is demotivated: Your team keeps complaining that working in the project is not as productive as it was in the past. A single person can’t build one feature alone; there are too many moving parts.
• Knowledge silos: There are some parts of the software that only a single developer knows well enough to maintain. It’s difficult for the rest of the team to work with that specific code.
• New developer ramp-up time is taking too long: When new developers join the team, it takes too much time for them to be fully productive.

The reason you got into one of these situations is probably not a technical one. Maybe you needed to deliver too much, too fast while you were building the first version of your product. Maybe your team didn’t have the maturity and experience in the past they have now. Analyzing the root cause is important too, but you need to do something else. You need to solve your problem.

If you’re experiencing the symptoms above, you probably have a low internal software quality problem. Recognizing the symptoms is already a big step. The next step is to think of solutions. Some solutions you may take include refactoring or a rewrite process.

Refactor or rewrite?

There’s no definitive guide about when you should do a big refactor or a rewrite, because it depends on a lot on your context. That said, there are some rules of thumb that you should consider when evaluating which solution to go with:

When to rewrite

• The technology you use is outdated, and it’s not maintained anymore.
• Your software is really slow, and changing the architecture is not enough or is not viable.
• The supply of software developers that know the technology you use is low and decreasing.
• There are new technologies that offer a significant advantage compared to what you’re using.

When to refactor

• The technology you use is still maintained and relevant.
• It’s viable to improve your application in an incremental fashion.
• The problem you’re solving is just technical and not a business one.

Choosing one of these options is not an easy decision, and once you go with one of them, there will be an entire new set of concerns you’ll encounter. Stay tuned, in our next blog posts we’ll talk about what to consider when doing a big refactor or a rewrite.

Now I would like to know about your experiences. Have you ever been in a similar situation? How did you identify that your problem was low internal software quality? Please share with us!

The post The Symptoms of Low Internal Software Quality first appeared on Plataformatec Blog.