I'm a new developer at a company that has had a very small development team (2-3 people) for a long time. All the current JIRAs are spoken for and there's no backlog. My big boss told me that since the development team is so small, the other employees are used to putting their needs "on hold" and I should go ask them what they want. I don't want to march into their office and demand to know what they want. What's a tactful, productive way to coax ideas out of someone and turn them into a viable project? I'm looking for a good introduction for when I go into their office and the sort of questions I should ask.

  • When you say "new devloper" do you mean you're new to being a developer or that you're new at the company, or both? – Daenyth Dec 12 '16 at 15:15
  • Both. This is my second developer job but I'm less than a year out of college. – user52991 Dec 12 '16 at 15:16
  • 4
    This is one weird company. – Jonast92 Dec 12 '16 at 15:18
  • 2
    Is the product an internal tool consumed by people within the same company, or is it something you're selling? – Daenyth Dec 12 '16 at 16:08

Don't just walk into their offices and expect them to bring up a list of issues on the spot. Invite them to a meeting, set up an agenda so they know what to prepare. Hold the meeting, gather ideas, write them up for your boss to prioritize them. Give feedback on what was prioritized to your stakeholders. Then start working.

| improve this answer | |

This situation is a little unsettling, to be honest. Some thoughts:

there's no backlog - Who is responsible for long-term direction of the product? Who are the product's users? What problem does it solve? Is there anyone on the team whose responsibility is determining direction? Why did they hire you if they have no work for you to do?

There likely is an existing unrecorded plan. Find out what the long term direction is, and what they intended you to do upon joining.

Record every idea you come across in JIRA. Don't worry about whether it's short term or long term goal, just get it recorded - from there you can begin prioritizing which items to do in what order.

I've also never seen a project that does not need some of the following:

  • Run through typical usages and note down areas that are confusing or complicated. Think of a way to improve the UI or UX here.
  • Ask people if they have any known issues or known workarounds, you may be able to make a solution to these.
  • Add documentation to the project. If there isn't a guide telling new end users how it works, make one. If there is one, follow the guide as if you're a new user, and make sure it's correct. Tie this into the UX examination.
  • Talk to end users or developer and find pain points. Make a solution to them.
  • Add more automated testing. Run a coverage tool and identify the least tested area of the code, and the area of the code that is most important to key behaviors of the product. Focus on creating tests there.
  • Do you have continuous integration running your automated tests on all changes that get made? Set it up if it doesn't exist.

Whatever you're doing, create tickets for the work and run it by your manager first.

| improve this answer | |
  • @downvoters I'd appreciate a comment if you think I've missed the mark here – Daenyth Dec 12 '16 at 16:34
  • To add to this, I've never found a development team that hasn't got some great ideas for small projects that they're lacking free time to work on – mfcrocker Dec 12 '16 at 16:42
  • The only type of software that does not need a backlog, is software that is not and never will be used. – Stephan Bijzitter Dec 12 '16 at 17:41

Why is there not a backlog?

This typically means there is no real thought in terms of the product(s) development. I would try to work with a business owner or such person to get the backlog built.

Not having a backlog ( stuff to do in the queue ) would make me nervous.

| improve this answer | |