I’ve been using this spreadsheet to ease the WSJF calculation, facilitating collaborative workshops with that.

Download the Excel spreadsheet here, or copy the Google Sheet here.
I’ve been using this spreadsheet to ease the WSJF calculation, facilitating collaborative workshops with that.

Download the Excel spreadsheet here, or copy the Google Sheet here.

I’ve created few years ago to prioritize product backlog, from epic level to user stories. It can be used on Backlog Refinement, Backlog Prioritization, Product Inception or even Design Thinking workshops.

Download the Excel file here, or copy the Google Sheet from here.
Reach: how many people will this impact? (Estimate within a defined time period.)
Impact: how much will this impact each person? (Massive = 3x, High = 2x, Medium = 1x, Low = 0.5x, Minimal = 0.25x.)
Confidence: how confident are you in your estimates? (High = 100%, Medium = 80%, Low = 50%.)
Effort: how many “person-months” will this take? (Use whole numbers and minimum of half a month – don’t get into the weeds of estimation.)
https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/
Lean Inception is a method to build a product focusing on Minimum Viable Products. MVPs like Lean Startup. It can help small or large organisations to realise what’s the priority to build next. It addresses a week-planned agenda with Product Development and UX techniques like Elevator Pitch, Personas, User Journeys, Brainstorming and Sequencing of Features, and the Canvas MVP, the proper result of a Lean Inception.

It was developed by the easygoing-geek genius Paulo Caroli from need. With his newborn son in 2011, it was virtually impossible to balance work and family running an old-fashioned Inception for weeks. More constrains, more creativity. Lean Inception was created to accomplish a product inception in a week.
A facilitator leads the process. Key business and product people do a kick-off presentation in the beginning about what shall be about the product, and for who. The team attends the entire 5 days agenda, presenting the results to those interested in the MVP(s).
However, even Lean Inception is a method, it’s not just about to build the next MVPs. As Dwight D. Eisenhower said “Plans are worthless, but planning is everything”. A perfect MVP planned is worthless without people engagement.
Lean Inception is about making people awesome, engaging them to build an awesome product.
Awesome because they are part of the process, part of the product. They feel like owners of the product, because they helped to decide what to build. Even business knows what to build and UX decided for who, it’s very important encouraging the team develop the product too, doing the Elevator Pitch and sketching Personas.

Discover more about Lean Inception at martinfowler.com/articles/lean-inception/ or reading the Lean Inception book.
Right after I woked up today, I read this Dan North’s tweet:

Trunk-based development makes the development teams integrate and test on a single code, which is the trunk (or master in Git). It is the base for Continuous Integration and Continuous Delivery. This approach brings software releases early, reducing time to market. At the extreme, Lean Startups.
Two weeks ago I was coaching an agile team for the first time, they use feature branches, having a slow cadence of deliveries. They are working on a single product with other three teams in their organization, plus other three organizations. In this case, code integration is a mess and its code is fragile. After a short time, business cannot have fast time to market anymore.
It is virtually impossible having trunk-based development without test automation. When you need to integrated code, you need to test the feature and every thing related. So doing it manually is insanity. Manual testing can be easy in the beginning, but the software becomes more and more complex. You need test automation.
First of all, your team have to understand the need of test automation. Secondly, they have to learn and practice test automation. Why not try coding dojos or mob programming?
Based on the Redundancy principle of eXtreme Programming, your team can automate tests on critical features, difficult problems, so it can be approached in many ways. Developers focus on unit and integration code mostly, even functional tests. Testers automate functional and many other types of tests. They help each other. There is no right division on that.
Keep something in your mind: “Legacy code is simply code without tests” by Michael Feathers. So every code you commit without tests, it is legacy code.
So cheers for good practices on software development…

Inside an environment highly demanding with frequent interruptions, people who work with technology need to be careful with their productivity. For that reason, I’m revealing seven secrets from my own experience. I hope they can be useful for you too.
Secret #1. Have a purpose
Firstly, do you really need to be more productive? Be more productive without a purpose is like a boat travelling on the high sea, going faster to anywhere. With a good purpose, your productivity will flow. Describe a purpose using objectives with goals. An objective is qualitative, like to work with new technologies to grow up in your company. A goal is quantitative and needs a deadline, like read three books of agile software development in the next two months. Each objective has goals, and each goal will be divided in tasks.
Secret #2. Work on a prioritized list of tasks
Make a list of all tasks that you need for your goals. How to prioritize tasks? Look to the importance and the urgency of each task. You can use apps running on the cloud to automatize your lists, like google.com/keep, todoist.com, evernote.com and rememberthemilk.com.
Secret #3. Visualize your progress
You will need small rewards, day by day, visualizing your work done. For that, you can use a task board, also called kanban board. A good app on the cloud is at trello.com.
Secret #4. Give the next step soon
Sometimes, you have so many important tasks to do that you might prefer to procrastinate. So, give the next step soon. Don’t wait a perfect moment. Just pull a task and start. Task by task, you will be rewarded with the feeling of accomplishment and motivation.
Secret #5. More focus
Focus is the key to be high productive. It happens when you use all of your capability for only one task. For this, use short periods of times (15-90min) to have high focus, avoiding at most anything that can interrupt or distract you. A simple and powerful technique for that is the Pomodoro Technique. One Pomodoro is a period of 25 minutes to work in one task each time, avoiding all distractions and interruptions. Set an alarm for each Pomodoro, you can use the alarm in your smartphone. Between two Pomodoros, take a short break of 3-5 minutes. Every four Pomodoros, take a long break of 15-30 minutes. There are some nice apps for that like e.ggtimer.com/25min or marinaratimer.com.
Secret #6. Take care of your energy
Yes, even techies need to care about the energy. Your mental and physical energies are the fuel of your productivity. So care about your nutrition, your hydration, your sleep, your body doing stretching and physical exercises, mainly the aerobic ones. You might boost your mind with meditation or mindfulness. If you have never meditated you might try the onemomentmeditation.com, or insighttimer.com.
Secret #7. Productive habits and routine
You need discipline to achieve high productivity in a short term. However, for a long time, you will need to care about your habits and your routine. Use your discipline to make productive habits, starting to build a routine during the first weeks. To acquire new and more productive habits is a process that might require some effort and time.
Top Secret #8
Yes, a top secret. Be resilient! Sometimes everything seems to go wrong for your productivity among interruptions and distractions. Don’t give up, persist! Face it like a challenge.
Focus!
A reader of our eXtreme Programming book asked us a guide to move from 0% TDD programming to 100% (or almost) TDD programming. But, there’s no manual that will really teach TDD, because it’s a practice. We could use a metaphor to explain it, TDD is like swimming, an activity that we practice.
Yes, TDD can be very hard at first time. Like swimming, you might not have enough breathing discipline, getting tired faster and giving it up. And after say “I didn’t like swimming, swimming is not for me”.
As a swimmer needs to jump in the water, a programmer needs to start with a failing test, write code until the test works, and refactor. And repeat these steps a lot of times. It’s a cycle, it’s a mantra:

After a lot of TDD cycles, you will be understanding how to practice TDD. So, please, jump in the water and enjoy TDD.
— Thanks to Guilherme Motta for the review.
Você precisa fazer login para comentar.