Earlier quoted context omitted.
It sounds like you're in a 'bugfix' position, and we found it hard to integrate that into Scrum, so I'm not surprised it's confusing for you. In the end, we ended up just saying that bugfixes were more important and slicing off some time for how much we expected, and using the rest of the time for Scrum. Once you get into Scrum, it isn't hard to remember the terms. A 'story' is just a feature to implement. It's calle…
> It sounds like you're in a 'bugfix' position, You might work differently, but that's not bugfix mode. Everything is an issue in an issue tracker is a development model followed by many projects. I don't think OP is in bugfix mode. > Once you get into Scrum, it isn't hard to remember the terms. So not very different from not having terms at all? Which is what OP is following. > A 'story' is just a feature to impleme…
Having a process that is transferable between teams and companies makes the lives of everyone better, and gets us to past a lot of the overhead that leads to unfulfilled goals and unrealistic deadlines. What if your team grows to 4 people, and they all have their own idea of how to get stuff done? Without some formality, it becomes the wild west. What if you decide to leave, will you leave chaos in your wake? What if management keeps bugging you about getting stuff done sooner? If there is no well defined process, then management may be left believing the software team just isn't 'professional' enough to get things done. With a well defined and understood process, everything can be tracked and people can be made accountable for their choices. We aren't talking about a witch hunt, it will allow the company as a whole to grow and get better at defining what can be accomplished in what timeframe. If everyone agrees to abide by the process, but continually subvert it (1 + 2 = 4), then you can either suffer now (work 50+ hours a week), suffer later (build up of technical debt), or find somewhere to work values building really great software in a coherent manner.
So what is Scrum? It's a process, as are Waterfall, RUP, and XP. Those of us that willingly practice believe it's a great way to achieve maximum visibility and minimize scope creep, all while reducing artifacts and overhead. It allows us to deliver value early and often. It gives developers the tools and justification to point and say "It can't be done given our constraints". Scrum is great for team ownership, and encourages us to get early feedback on features.
Regardless of how you decide to get stuff done, make sure you have 100% buy-in from the people cutting the checks. This whole topic reminds of the discussion on designer pricing (http://news.ycombinator.com/item?id=3042803). We assume non-technical team members (our customers in many cases) implicitly understand what it takes to get a product shipped. We must do our best to bridge the gap between expectation and reality.