The good news is most sites realize we, the users, need nudges to create strong passwords. The bad news is too many of those nudges reject strong passwords from password managers. (I use and am happy with 1Password.) Worse, too many sites still ask horrible, terrible security questions instead of asking for two-factor authentication. Your […]
You’re a busy product person, a Product Owner. You have information the team needs, and you want to meet. A lot. You see the need for these meetings: Standups Backlog refinement Iteration planning Strategic updates, so the team knows what’s going on. Sounds reasonable. Except, the team thinks you want to meet too often. What
Michael Mahlberg taught me something cool last week. We’re writing an article together. Part of the article is about forecasts. I was ranting and raving about how to help people see their confidence levels. He pointed me to this slideshare: Lightweight Kanban Metrics (in German). (Don’t worry about the language.) Go to slides 24, 25,
Several of my clients have intertwined problems. Everyone agrees they want innovation: Which products and services the organization offers. (The project portfolio) What features the product offers, or the problems the product solves. (The product roadmap) In the team, to solve the problems in a way that will attract users/buyers/customers. (The team’s backlog and how
I spoke with an agile coach whose team works in flow, similar to this board. They don’t use iterations—they plan on demand. The column on the left, “Stories to Workshop” is their backlog refinement column. Recently, the team decided they need “minimum” WIP (work in progress) limits. Especially on the Workshop column. Why? Their product
Many of my clients use an iteration-based agile approach. And, they have these problems: They “push” too much into an iteration. They use velocity, not cycle time to estimate. They rarely finish everything before the iteration ends. They have to manage extra work—work they had not estimated—in the form of an emergency or production support.
Do you have trouble fitting “all” of the necessary work into an iteration? Your managers might want to push you to do more. Or, the product owner thinks you can do more. Or, the team wants to do more (see Beating a Team’s Goal.) Agile approaches are not about doing more. Agile approaches encourage us
A colleague asked me about the kinds of documentation the team might need for their stories. He wanted to know what a large geographically distributed team might do. What was reasonable for the stories, the epics, and the roadmap? How little could they do for requirements documentation? I start with the pattern of Card, Conversation,
I started this series discussing the issue of the various product-based roles in an agile organization. I suggested a product value team because one person becomes a bottleneck. One person is unlikely to shepherd the strategy and the tactics for a product. And, batching the product planning in one-quarter chunks doesn’t encourage us to reduce
Many people in the agile community promote a product orientation over a project orientation. That’s possible because an organization has product or feature teams. That works until you have more products than teams. That’s when you might still need projects to accomplish everything. If you keep teams together, you can still use projects in a