In my career as a developer I had worked with multiple formal project management methodologies (Scrum, Kanban), the most productive team I ever worked for was in an startup that did:

  • A simple to-do list for the entire project, where each developer had some of these tasks assigned to them
  • Each tasks had a point score estimating tasks difficulty, given by developers on project planning, these points where used for time estimation
  • Tasks could be added, or reassigned at any time, thus re-estimating delivery dates
  • Multiple delivery or demo dates could be estimated simply by adding tasks points until the desired point in the project
  • Our manager had an average points/week for each developer for date estimation

Is this considered Scrum? Or what's the name of this method?


  • 1
    People sometimes create their own methods, so we can't really tell if you were using Scrum. You can go to scrumguides.org/scrum-guide.html and see if the practice you followed is in tune with what the guide says. Pay attention to the end note in the guide, that says "The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices." – Bogdan Jan 19 at 19:01

Your description seems much more like Kanban than Scrum (continuous delivery rather than fixed iterations). Points-based estimation is not part of Kanban or Scrum but it's usually important to do some kind of estimation and relative estimation using points tends to work well for software projects.

I would not classify this as "project" management; it's just a way of working that continuously delivers useful work. The existence or absence of a project context is not important and what matters is that you are delivering value. Avoid the word methodology is my suggestion.


From this description, it is impossible to conclude what this methodology is. Just a list of tasks with estimated importance and timeline - it can be classified as a waterfall even (tasks/tickets, in particular, doesn't mean anything).

Please either add details regarding change in priorities or tight deadlines shift or etc.

Otherwise, it's just a successful case when nothing interrupter the initial plan and none of the practices of agile project management was required to be applied.


As described, this feels like a pragmatic approach based on taking bits of waterfall, bits of Kanban, and maybe bits of Scrum too. I agree with NVogel that it probably isn't a methodology as such, but it does feel like a self-directed form of project management. What isn't clear from the description is the role of the PM in setting priorities, reporting, managing risks, monitoring progress, etc.

I used a similar approach when I joined a small company which had never adopted any formal methods. We simply described it as "An Undefined but Pragmatic Project Management approach" if asked what our approach was. My team was very small and training them to use formal methods seemed inappropriate, when we were not expecting to run a constant diet of projects (the same team would take the resultant solution into support, care and maintenance once the project was completed.)

I would suggest that you don't worry about the name of the current approach. However, I would strongly suggest that you consider whether you should be moving the team towards a more structured approach that would allow new members to join the team, and give you, your team, and your organisation a chance to exploit the learning that has been developed and documented by many experts over a long period of successful project delivery elsewhere.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.