At our company we have a team working on 3 different projects at the same time, where typically only one or two people are involved in each project. Project work often involves mastering new technologies and or solving bugs, both leading to tasks which are very hard to estimate. In this situation, the management still insists on using SCRUM and does not allow allocating a safety buffer at the end of the sprint for unexpected situations. The stand-up meeting happens for the whole team, although pretty much everyone works on unrelated software components or different software projects all together.

  • I was wondering if someone have seen SCRUM working well for a project with a single developer and fuzzy tasks, and how you made the process work well?

  • How to estimate tasks which involved research/mastering new technologies (this involves learning new programming languages, platforms, and development tools)?

  • Has anyone succeeded in convincing management not to use SCRUM for particular projects, and if yes, which arguments were most successful?


  • Looks like your management likes to use fancy word without even understand what is behind that word. No Scrum is not for your environment and it sound like you should look for another job. Doing every task in another technology is most probably waste of your time. Jul 2, 2011 at 21:02
  • 1
    possible duplicate of Using Agile development in a one person team
    – vartec
    Jul 4, 2011 at 11:06
  • 1-person scrum = discipline. You simply have to learn to do most important/risky things first. This is ... common sense.
    – Job
    Jul 21, 2011 at 18:35
  • it sounds like, "the management", don't understand Scrum from an organisational perspective. The projects should get a time slice each and you should work as a team. Give "the management" a copy of Succeeding with Agile: Software Development Using Scrum Aug 27, 2013 at 9:13
  • It's not possible, by definition. "Scrum-like" is possible and could be productive or antiproductuve, but you need to sit down with mgmt and a checklist of what pure scrum means, and decide which aspects you want to follow. Whether or not you continue to call it scrum, doesn't matter, so long as everyone knows specifically what's desired. Also try to understand mgmt's perspective and what they're trying to gain out of the process.
    – Dax Fohl
    Jan 10, 2016 at 21:54

6 Answers 6


Look up "Personal Scrum"... I've seen a couple or three blog posts of people doing this. Full Scrum has some notions that won't translate perfectly to single person teams. (My experience -- a certain "critical mass" of about 4 people seems to make team-stuff work well.)

https://jgpruitt.wordpress.com/2011/04/10/personal-scrum/ for example.

But things like task estimation, velocity, and time-bound sprints during which the task-list is "protected" work well even for 1.

  • +1 for a good link to a whole graduate project using personal Scrum: "the entire project has been chronicled in the materials below. To my knowledge, this is the first fully documented instance of a Personal Scrum project, and it is certainly the most open."
    – Hugo
    Jul 3, 2011 at 7:45

Of course not. Your daily scrums would be very short, and incredibly boring!

You can cherry-pick the bits you think would help you though, cards make sense though you don't have to fill them out so fully; stopping after a set amount of time to check your progress makes sense too. But if you're doing that, check out Kanban, Crystal and all the other Agile methods too for bits that would help you.


No you cannot do scrum without a team. Team defined by SCRUM is "A cross-functional group of people responsible for managing itself to develop the product" which is an important role in SCRUM.

According to http://www.scrum.org/storage/scrumguides/Scrum_Guide%202011.pdf

Development Team Size Optimal Development Team size is small enough to remain nimble and large enough to complete significant work. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog

However you can still be agile, and maybe use the other characteristics of the SCRUM like maintaining product/sprint backlog and planning & working under sprints/iterations, reviewing and getting feedback from all stakeholders and re-planning and so on. Please read more about scrum as it is much more to it as described here.


I am working in a similar shop. As others here noted, what you describe may be agile but not scrum. I would also add that whether or not back logs and sprints makes sense depends on if it is new work or maintenance and on-going support. If the former, then a waterfall approach would make more sense for a one-person team. If not, from a PM perspective, what they are doing seems like a good approach if they have multiple projects in their portfolio.

To Agile enthusiasts, the mere mention of using waterfall is sacrilege. But people need to use common sense.

Let me give an example from a recent project of mine. I was leading a team of 3 developers on an aggressive 5-month timeline to redesign two major websites. We had daily stand-up meetings. But it was a waterfall project because it was a small team, limited life cycle, and the developers were all short-term contractors committed to the project only until launch. The project followed a very traditional waterfall life cycle. Absolutely nothing wrong with that. Except we did work in an "agile" way, we kept the stand-up meetings and we kept agile development best practices. Our small team was exempted from the larger team's weekly sprint planning meetings. Why? Because we didn't have weekly deployments. And our team didn't depend on or influence the work being done by any other team. In fact, we worked almost autonomously. After the websites launched, we then transitioned over to an agile process for on-going maintenance and support. The other developers are now working elsewhere. All enhancements are planned according to periodic deployments.

The point is, it is better to use the processes that makes the most sense for the size, complexity, and the maturity of each project. If you're doing a lot of research, then it's hard to make an estimate for the next five months, so agile is probably a better approach than waterfall.

Part of the problem is that some people seem to think you be able to plan the next five sprints out in advance. That's been the case with me before. You should not be planning more than two sprints out because if you are then you are defeating the whole purpose of having sprints. A sprint is supposed to be a commitment to deliver a realistic quantity of enhancements within a set amount of time. You should not commit to something you're not sure of. Sprint planning is by its nature short-term planning, but that's kind of the point. If you have a long-term schedule, then think about breaking things down into smaller deliverables. Or setting up checkpoint meetings based on where you are in the SDLC.

Sprint planning is supposed to be a realistic commitment about what is guaranteed to be completed within a certain time frame. If you find that the planning is not accounting for unknown variables, perhaps you should start giving ranges or pessimistic estimates. Or as other suggested, use story points. Sprints also should not be booked completely to allow for slippage and other important tasks that come up.


There shouldn't just be one person on your team and I doubt there actually is. A "team" in SCRUM is not just the developers. Are you the customer representative, scrum master, developer, etc...? Are you really the only person doing anything related to this product, making decisions about it, or trying to sell it?

As to estimating research, you do it as a story. You make a story specifically for, "Research XXX," and give story points for it (remember, you're not estimating time here, but difficulty). You should also be able to fairly adequately estimate the difficulty of implementing some feature even if you need to research technologies. Sometimes this latter fact simply turns a story into "maximum difficulty".

No, you really shouldn't be meeting with all developers as your standup. You should be meeting with your team, which again is not just the developers.

Good luck. Hope you guys get it figured out.


Assuming you do have a product owner and a scrum master (if not then its not scrum), scrum can work for one man team. Scrum artifacts (backlogs, burddown charts) will be used just like they are used in multi-people team. Now about meetings:

Daily Standups: You would use daily standup to update everyone i.e. product owner, scrum master or anyone else interested in the progress. Scrum master will use this meetings to learn about any impediments you have. Product owner can help you with scope revisit if/when needed.

Sprint Review: At the end of each sprint you would handover working increment of your software to product owner or client. If goal of sprint was to learn "something" you will demonstrate a PoC that can be used by management (i.e. generally client for PoCs).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.