Best of luck to you! Having said that I feel this is a tough space. Most developers spend a lot of time in different ticket systems at work and for the most part they suck. So when we want to scratch our entrepreneurial itch it’s easy to look at software we use often. That makes the space very saturated and it’s difficult to differentiate your product. Also, all ticket systems I’ve used are bad, but the companies I worked for still paid a lot of money for them, so maybe UX isn’t a factor when buying these systems?
Thank you, I've been wanting to build something that works well for myself. After reading Jeff Sutherland's book, my ideas came together to the new layout and the design.
I don't know how far this will go or if it'll be successful, But I gotta give it a go.
Why does so much effort go into tracking and managing programmers? Does the customer care? Does it actually improve quality or delivery? Is it really any better than just letting people work?
My customers care at a high level - they are loyal to our product, and perform the majority of their jobs using our tools. They need to plan their own projects based on the release dates of our features, so they need to know if a feature is 3 weeks, 3 months, or 3 years away.
To be fair, they do not care about any specific individual developer. And I don't bother tracking individual dev performance. I track the overall delivery cadence.
Where I do care about individual developers is knowing how much they stay on-task. My teams vary from someone who will always do exactly what is outlined in the ticket, to people who second-guess and redesign the work (sometimes for the better, sometimes not), to people who go off the rails and design grand future visions that we then need to scale back to reality.
All of those people have value, but I need to manage their working style to the short-term business needs when planning upcoming work - sometimes I can let them fly free, sometimes I just need someone to put a freaking button on the screen and ship it.
So yes, it matters... micro-managing is pointless, but high level tracking helps set the correct pace of delivery.
Very valid questions to which you are not going to get any reasonable answers.
It is more a power play by the "Management" rather than satisfying any actual need. While some amount of management and issue/time tracking is necessary the intense focus on the same by Agile/Scrum is useless and counter-productive.
Hey Hacker News crowd. After a year or so toying around with my idea, thinking about the new approach and talking to people, I have decided to build a new scrum based project management app. It's going to revolve around a new board layout and concept and include the important bits of the scrum process.
If you're interested, sing up to be notified when I have the beta version ready. Hopefully in a month or two. If not, tell your friends.
The page is too light on details. What is different about this vs the hundreds of alternatives out there? Why would I switch from a different product? How do I know if I'm your target buyer?
Just put the page together this week. Will be adding more detail to it. The idea is to get away from the kanban board look and to help you track your sprint flow. Capture standup notes, sprint planning notes, manage backlog more effectively.
I just wanted to see if there was interest. Looks like there is. That's awesome.
I'll spend some time this week adding more details to the page.
> The idea is to get away from the kanban board look and to help you track your sprint flow.
Can you say why? Kanban is literally the only thing I like about capital-A Agile. I doubt either of will convince the other to change our minds. But in the interest of helping you refine what you’re building and how you communicate it, articulating what you don’t want is valuable too.
Originally Kanban was designed to visually track inventory. It is useful in that context because you could easily spot the items that need refilling.
I've been doing project management for a over a decade now and from my experience, and interviewing people, reading, I realized that people work best in lists. Top to bottom, most important tasks at the top, least important at the bottom. It helps us focus and get more done.
Thanks for the response. I’m more confused than when I started.
You’re saying Kanban was designed to track inventory. I think that’s true but not completely accurate. It was designed to track work and inventory together.
> people work best in lists. Top to bottom, most important tasks at the top, least important at the bottom. It helps us focus and get more done.
I’m so confused! This is exactly what Kanban is supposed to be. It’s not supposed to be anything more than that, or less.
I love the UI. Clean, focused, and specifically tailored to scrum.
I think sprints enforced by the interface is critical to keep management on track. The companies I worked at which used Asana, Trello, or free-form task lists were a mess. It was maddening not having a single schedule.
Once again, best of luck!