 |
| [image credit: izhar-ahamed on pixabay dot com] |
- Doing the "smallest thing" – may not necessarily be the smartest thing.
- To eliminate unknowns, risks – or to determine whether something will meet a particular Non-Functional Requirement (NFR) – the smallest thing may not be the correct choice.
- This is especially true when a critical cusp is reached.
- "He grokked that this was one of the critical cusps in the growth of a being wherein contemplation must bring forth right action in order to permit further growth." [source]
- Often, when establishing an architecture runway, experiments are required – especially with new technologies.
- See "Knowledge Acquisition" (re: "... you gather information to accomplish future tasks. When you identify a feature that needs further research, you create a knowledge-acquisition task, such as a prototype, experiment, or proof-of-concept, to gather the information you need.")
Michael Switzer's LinnkedIn comment:
"...combining new ideas with your previous ones will produce something completely different."
— Steven Johnson
"Guillermo del Toro is famous for compiling books full of notes and drawings about his ideas before turning them into films, something he regards as essential to the process. ..."
– Trivia for “El Laberinto del Fauno” (2006) on imdb.com
“Sometimes I have a good idea, something I wish I could remember, and instead of writing it down, commit it to my memory only to disappear when I needed it. Write your ideas as they come, if you wait it will be too long and you may not recover it. It may get destroyed as it is to seed to and fro in the ever rushing river of our thoughts”
― Bangambiki Habyarimana, Pearls Of Eternity
“Write down the thoughts of the moment. Those that come unsought for are commonly the most valuable.”
– Francis Bacon
“Keep a notebook. Travel with it, eat with it, sleep with it. Slap into
it every stray thought that flutters up into your brain. Cheap paper is
less perishable than gray matter, and lead pencil markings endure longer
than memory.”
– Jack London
“Well you know, for my experience, your head's for having ideas, not for holding them.”
– David Allen
“Get your ideas on paper and study them. Do not let them go to waste!”
– Les Brown
“Remember, my friend, that knowledge is stronger than memory, and we should not trust the weaker.”
– Bram Stoker
“I take notes like some people take drugs. There is an eight-foot
stretch of shelves in my house containing nothing but full notebooks.
Some would call this hypergraphia (Dostoevsky was a member of this
club), but I trust the weakest pen more than the strongest memory, and
note taking is—in my experience—one of the most important skills for
converting excessive information into precise action and follow-up.”
– Tim Ferris
More quotes:
- https://inkymemo.com/famous-quotes-about-notebooks-and-writing/
- https://www.silkandsonder.com/blogs/news/32-of-the-most-famous-quotes-about-journaling-and-writing
Considering some variations in Product Backlog Definitions:
André Bernardo offered this definition of a Product Backlog:
"A product backlog is a problem space for solving user friction, bugs, and technical tasks"
However, many organizations use very different definitions of a Product Backlog [wikipedia.org]:
- "... is a list of the new features, changes to existing features, bug fixes, infrastructure changes, or other activities that a team may deliver in order to achieve a specific outcome." [source]
- "... contains a prioritized list of work items, including user stories, features, bug fixes, technical tasks, and research activities needed to improve the product." [source]
- "... is a comprehensive, evolving list of all desired work on the product, while the sprint backlog is a subset of items selected for completion during a specific sprint." [source]
- "... represents the long-term, prioritized list of desired work, including features, enhancements, bugs, and technical debt." [source]
- "... is an emergent, ordered list of what is needed to improve the product." [source]
- "... a prioritized features list, containing short descriptions of all functionality desired in the product." [source]
- "... Option Pool: Lean" [source]
- "... work with stakeholders to select the highest value work when they have the capacity to perform the corresponding work. In effect prioritization is done on a just in time (JIT) with the team’s stakeholders."
Although there may be strongly held opinions about different definitions, adopted by different people, I think we likely agree on some very common ground, more than they may think ("focus on the next most valuable thing" ) - which does not conflict with allowing the Product Backlog to include possible future ideas for improvement, or future features - which may fall out over time, if they are not prioritized for inclusion in future sprints.
There is nothing inherently static about a Product Backlog, based on any of these definitions. It is important that it be maintained on a continuous basis. If someone projects an idea onto the concept of a Product Backlog as a static list - that is an aberration, and likely a projection of a very skewed understanding of how it has historically been defined.
(APL) as an important
influence in the patterns world.
— John Steinbeck
— Will Self