My team has a lot of small pieces of work as we are in the final parts of the project where there are lots of little things to fix. Trying to manage this has been difficult.

The problem is the Scrum board doesn’t have categories which are useful for development. "In development" just means someone has written code for it. It could be anywhere between them just starting or it awaiting code review to merge to master. It also doesn't have space for tracking things like which branch has which features in it. Not having this has meant that we have shipped builds which are missing things as we just forgot about them.

We wanted to create a duplicate board (different from the one the product owner gets to micromanage) for the purposes of development as we need to know in greater detail where each piece of work is. But this was disallowed by the Scrum master as too confusing for the product owner (why she needs to see it, I have no idea).

I am not really sure how else we could organize it, especially remotely. How can we organize this kind of information without using a board or table?

  • Lots of free project management software out there...
    – Solar Mike
    Jul 3, 2020 at 23:03
  • Yes but it cant be a board. Jul 3, 2020 at 23:37
  • 2
    Is this about your sprint backlog specifically, or about the main product backlog? Because according to Scrum, the sprint backlog is yours (as a dev-team) and you organize however you want to get your work done. You might want to discuss that with the SM.
    – Erik
    Jul 4, 2020 at 6:56
  • 1
    If the scrum master disallowed something, surely they must have suggested an alternative. If they didn't suggest a workable solution, go to your boss and ask him to fix the issue the scrum master is causing.
    – Jeffrey
    Jul 4, 2020 at 15:24
  • 2

5 Answers 5


The scrum-by-the-book way would be to improve your actual scrum board by splitting "In Development" into more columns representing the different states a task can be in.

When your scrum master doesn't see the value in doing that, make them understand the value or find a different scrum master who actually understands that their job is to help the team, not to be in their way. Scrum doesn't say anything about which column your scrum board needs to have. That solely depends on the workflow of the team.

  • 10
    Yes. The scrum master's job isn't to tell you how things should be done. They are meant to be the person who is there to remove problems that still the developers getting on with useful work instead of wasting time on logistics, admin, proceses. Teams should be free to adopt whatever internal processes they like to do the actual work, as long as the sprint goals and team capacity are accurately communicated to product owners. In practice, most companies using agile insist on imposing procedures on teams, and there's not much they can do about it.
    – PhillS
    Jul 4, 2020 at 10:15

The Scrum answer to this is: speak about it in your retrospective. Bring up the problems you have and decide on a solution.

Common is:

  • having more columns on your sprint board than on your backlog board, so stories in development can have a more fine-grained status.
  • having a naming convention that makes clear where the code is (i.e. the ticket number is used as the branch name)

But the main point is: don't let your Scrum Master off the hook. Denying something is not their job. Their job is to help you as a team to find a solution to your problem. Demand that you fix the problem together. "We should find an alternative, lets' talk about it" is a good answer from a Scrum Master, "No" is the answer of someone who failed their job of Scrum Master big time.

And a word of advice: do not let a tool dictate how you work. "Our management software cannot do this" is not what Scrum is about. If you can do it on a piece of paper and it works for you, that's good enough. Scrum is not about following a software product and it's shortcomings, it's finding solutions that work for the team.

  • 2
    So does Scrum give you a method to replace a poor manager? That seems to be the issue...
    – Solar Mike
    Jul 4, 2020 at 11:32
  • hm, I don't know, I haven't heard a word about a manager in the question. As far as I know, no method gives you a process to replace people. That's an out-of-process problem.
    – nvoigt
    Jul 4, 2020 at 11:36
  • 2
    The scrum master (setting aside my problems with that term in general) isn't a manager, though being forced into that trap is a common failure mode. As always, there's the methodology on paper, and then there's the methodology as actually practiced. The scrum master is, per the Scrum guide, "a servant-leader for the Scrum Team." Resources like The Manager and Scrum discuss what the manager's role is supposed to be under the methodology. Jul 4, 2020 at 18:46

Cant you just have an off the books board?

Create a thing in Excel/SharePoint/Google Sheets, share it via email with the relevant team members only, and just work from that. Your mistake is in asking for permission rather than just doing it and waiting for it to be discovered.

  • 3
    Asking Scrum team members to go behind the back of other Scrum team members is really not what Scrum is about. That might work for more dog-eat-dog methodologies, but it is really bad advice if doing Scrum.
    – nvoigt
    Jul 4, 2020 at 6:31

I'll skip over the whole issue of how agile should be about letting teams be free to modify their internal processes to find something that works efficiently for them, since other answers have covered that.

Does your scrum board software allow for sub-tasks within each story that aren't shown on the main board (only visible within these ticket for each story)? Of so you could try creating tasks for each stage : coding, writing unit tests, QA/ manual testing, code review, merged to master). Each task can be marked as done when completed, and anyone looking at the story ticket can easily see which tasks are still to do before the whole story can be closed. Meanwhile the actual team scrum board still shows what it did before.

But that's just trying to find a workaround acceptable to the basic fact that a) your scrum master is trying to dictate how the developers organise their work and b) puts more priority on making infromation visible to management than on getting production work done properly. Ideally the solution would be to convince your scrum master that imperfect management information of effective work trumps perfect management information of poor work. The problem is that management often don't see it that way, so your scrum master's performance reviews, KPIs and bonuses may incentivize exactly what you are seeing. On a practical level, asking your scrum manager to hurt themselves financially and career wise to make your life easier obviously isn't going to work.

In which case you need to stop seeing the scrum master as the problem and make them part of the solution. Explain to them the difficulty the current system creates in terms of important work getting overlooked because the team can't adequately keep track of it. Ask them for their help and suggestions for finding a solution. Listen to them and understand the constraints they are working under that might not be apparent to you (or might be completely idiotic and imposed from above, but you have to deal with reality as it is, not as you'd like it to be). Ask what you can do to make their job easier. Emphasise that you want to find a solution that works for them as well as you. Surprisingly often, just taking the time to understand their point of view and empathise with them will make the problem go away. Or the discussion will point the way to a mutually improved solution. I guarantee that your scrum master is operating under at least one important constraint (whether externally imposed or due to internal motivations) that you are oblivious to.

It may be a cliche, but "'No' isn't the end of the discussion, it's the start of the negotiation". Coming along with your own solution out of the gate that hurts them isn't negotiating. Going to them with "This is the problem that exists, and we'd like your help in figuring out a good solution" is the start of a negotiation.


For all the talk about Scrum giving the development team freedom, there are a truckload of pallets of cases where the development team is basically being strangled by all the institutions and power structures it creates. A sprint belongs to the self-organizing development team, my ass. Developers can't even set up their own organization tools...

One of the advantages of Scrum stripping developers of their autonomy is that organizations that use Scrum usually don't trust developers to do much more than their tickets. Leverage that, especially now that you have had your ability to solve the problem prohibited.

Just do your work and let the product owner complain about anything missing.

Everyone praises doctors. Nobody likes the nutritionists. Transform the problem from one that needs a nutritionist (proactive solution) to one that needs a doctor (reactive solution).

  • Can you explain why you think Scrum created any of those power structures? Right now your post reads as if you don't know what Scrum is supposed to be. Is there anything in the Scrum guide that prohibits developers from setting up their own tools? Is there anything in the Scrum guide that says the organization should not trust their developers? Is there anything in the Scrum guide that says the Scrum Master can deny things?
    – nvoigt
    Jul 4, 2020 at 7:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .