Board/Sprint updated with new tasks

Personally, I think your statement shows a desire for micromanaging.  

If the activities the Developers are undertaking are being discussed everyday at the Daily Scrum, they are being transparent with each other.  Does anyone in your organization other than the Developers doing the work really need to know all the minute details?  There is a line between necessary work and busy work.  

There is a principle of the Manifesto for agile software development that I value. It listed 10th.  It says 

Simplicity--the art of maximizing the amount of work not done--is essential.

Transparency of the work does not mean that infinite details must be provided in multiple places.  In the case you are mentioning I would think that the transparency is available to people that need to know, especially if it involves coding.  The code base will provide transparency of the work.  The board is not the only way of being transparent.  

How would you deal with that?

By encouraging the Developers not to dwell on who did what yesterday, but rather on coming up with a plan for the next 24 hours which they collectively agree to.

How would you deal with that? (How would you make people aware of the importance of creating tickets for "each and every task" they perform and to add them to the board/Sprint?)

I can't. I'm scratching my head about why that would be important, or what such detail would be used for. It's more important that they collaborate over their plan and jointly inspect and adapt it. To that end, they just need a consensus view of the work that they currently believe remains to be Done.

I would say it shows a lack of Transparency. Would you agree with that?

It suggests a lack of collaboration and joint focus. Putting transparency over which individual has done what is poor compensation for half-hearted teamwork.

What is your role on the team?

The Developers are fully responsible for the Sprint Backlog and however it's made transparent among themselves and to stakeholders. No one can mandate the Developers to use specific techniques for conducting the Daily Scrum and managing the Sprint Backlog, but there may be opportunities for the Developers to receive feedback on their efforts to make the work visible and transparent - one such opportunity is the Sprint Retrospective. As long as the techniques are working for the Developers and they are able to inspect progress, make adaptations to get closer to achieving their Sprint Goal, and make the work transparent, how they run their Daily Scrum or manage their Sprint Backlog is of no concern to me unless they ask for feedback or suggestions.

If a Developer on the team did ask me for feedback in this situation, I'd have a couple of pieces of advice.

Part of my advice would mirror Ian's - the purpose of the Daily Scrum is to plan. What the team is going to do today to get closer to the Sprint Goal is far more important than what the team did yesterday.

I'd also ask the team to look at the granularity of the items in their Sprint Backlog and see if it makes sense, to them and to promote visibility to key stakeholders. It very well could be that X and Y are parts of something else on the Sprint Backlog, but not explicitly visible by themselves. If knowing that progress was made on X and Y is important to someone else, then perhaps X and Y should be on the Sprint Backlog. However, it may not necessarily be important for anyone else to know about X and Y and even getting into that level of detail is too much for planning the day at the Daily Scrum.

The first question is: Why do you and/or the organization want a ticket for every task they perform?



If they don't need them to do their thing, it's for someone else.

First of all, thank you everyone for your precious comments! I agree with you when you say the most important discussion at the Daily Scrum is about how we can collaborate together towards the Sprint Goal, and that Sprint Retrospective is one of the occasion to discuss topics similar to this one. Let me give a bit more context and my thought around this topic.

"As long as the techniques are working for the Developers and they are able to inspect progress, make adaptations to get closer to achieving their Sprint Goal, and make the work transparent, how they run their Daily Scrum or manage their Sprint Backlog is of no concern to me unless they ask for feedback or suggestions.": As a Scrum master (and sometimes Developer) in this team, perhaps I assume the "teaching" stance more than I should, - above all for some "basics"/pillar topics (e.g. transparency, board/flow management, even if that is more a Kanban concept) - which implies I could more tend to give instructions/suggestions (sometimes even "bad ones") or other perspectives when I think they can be useful, for example in terms of mindset - unfortunately, despite myself, that might lead to some sort of micro-optimizations/micro-management.

The organization does not firmly impose having one ticket for each task. Why I think it is useful to have a ticket for most of tasks performed? Personally, I think that having a fairly medium-level "detailed" (not low-level) board/Sprint Backlog enables having historical data-driven discussions within the team: for instance, the "number of tasks added during the Sprint" - most of the time, these tasks were not known/planned at Sprint Planning - may give a hint about "why we did not achieve our Sprint Goal this Sprint?" as well as give a slightly better overview and "credit" about the number of tickets "and Story Points" completed in order to help planning next Sprints. 

I know the number of tickets and story points completed are not "that important" in Scrum. Nonetheless, when I said something like "give credit to the team", I also wanted to say that the concepts of "efficiency/effectiveness" within the organization should be reconsidered (as part of the "ongoing Agile transformation") from output focused to outcome focused.

In that case, I would bring it up as a subject to talk about in Retrospective, and be sure everyone understands that it is temporary, and meant to better understand how correct grooming, estimations or rightsizing efforts are.



If it's temporary, people can do the extra effort. And then in one of the next Retrospectives (or in a separate meeting), discuss the experiment and the results.



Now, I've been a developer: this type of administration is annoying, distracting and unsafe, so most Developers do not like to do them. But, if it's an experiment, they'll try their best effort.