| I feel like there are some very precise ways to think about these things. For example, a backlog is a priority queue. A priority queue can only be long if work is added more frequently than it is removed. Work can be removed if it is either completed or abandoned. Work can be added when users request features, users find bugs, product owners predict features will be useful, or the dev team adds technical improvements. Talking to users will increase the bugs identified and the user requested features. So by these relationships, talking to customers will directly increase the size of the backlog. And the overall backlog length may be large due to many factors unrelated to talking to customers: slow development, never deleting out of date work, adding too many technical tasks, adding too much unvalidated vision work, etc. Does anyone know of any books, blogs or youtubers that bring this kind of logical system level thinking to software work management? |