Learn More
Resend Email
2
Rikan
5y

Has anybody experience with Scrum in small web development agencies? Especially estimating stories with story points instead of hours/days?
We have a new junior project manager, without any practical experience working agile, who wants to establish scrum because what he read about it sounded so good... I already worked agile with kanban before and I loved it, but I only have little experience with scrum.
I think scrum, or agile in general, won't work with the clients we have. Most of the time, our clients have a fixed deadline, a fixed budget (either money or time) and they know their requirements, so there is no much room for beeing agile.
Regarding story points, I just adding an unneccessary layer of abstraction, because the customer wants to know how long a specific feature takes. Sure, story points are just another, more dynamic unit for time, but then why nut estimate in static time unit in the first place? Another fear I have, is that some devs may be more ignorant regarding deadlines and expectations on customers side. "yeah I'm working for 10 days on this story, but it's 8 points!" instead of informing the project manager "Currently I spend 2 days on this feature, we estimated 3 days, but it seems I need 3 days more".

Maybe I shouldn't be worried, but it would be great if you could share your experience and learnings. Thanks in advance!

question

development

project management

scrum

agile

agency
Favorite
Ranter
Comments
  • 1
    5y
    Both have pros and cons. I do understand doing hours and points. I worked with both poker systems and both "scrum" and "kanban" and both as dev as as Product owner.

    From a developer point of view I prefered points over hours. Points are relative to eachother where hours are absolute. When a feature is taking more time than anticipated you might start thinking the other tasks are undervalued as well. With points you don't take in account time but difficulty (both implementing, testing and other related things)

    From a product owner it depends about knowledge and communication. I talked with my teams on a daily basis, casually just asking about it, no pressure at all. In that case I prefer story points.
    Is the product owner a person in the customers company then hours may be preferred.

    ......
  • 0
    5y
    ......
    About Kanban vs Scrum, they are really similar but scrum is a bit more strict. Neither of them is better than the other. I would say if in doubt do scrum but let it loose a little when you notice that is possible
  • 3
    5y
    My team slightly modified scrum because we found story points assigned were arbitrary and different depending on the person. It was taking too much thought and time to estimate the story points using the scrum scale, so we made our own. There are 10 workdays in a Sprint for us...We estimate 1 point per day we think a ticket would take. Then we also place more weight on estimates from the team mate most likely to pick up a ticket. Overall, we love Agile with our daily scrum sessions, and demos at the Sprint review have turned into an activity we actively look forward to. We used Kanban early on, and it was ok, but Agile with Sprints has been more motivating.
  • 0
    5y
    @aspenscythe how long did you try working with points? It should take 3 or 4 sprints to get to eachothers values.
  • 0
    5y
    I want scrum
  • 0
    5y
    @aspenscythe @Codex404 thanks for your feedback, I'm curious if we will try scrum and especially how it does work with and for our clients
  • 2
    5y
    > We have a new junior project manager(...) who wants to establish scrum
    He needs to stop that. If the team wants to establish it then by all means he should support you. But if he wants to establish something just because he likes it, he's making himself an obstacle for you. Reducing your productivity.

    > Sure, story points are just another, more dynamic unit for time, but then why nut estimate in static time unit in the first place?
    Story points are not a measure of time, they are a measure of *complexity*. In my experience, there is no linear relationship between SPs and time. IOW you might be able to finish twenty 1 SP-stories in the same time as one 8 SP-story, for example. Less common but possible: A stupidly simple but still time consuming task. Maybe that is what you meant.
    That's one reason why I think "sprint velocity" is a useless metric. And I prefer "t-shirt sizes" to numeric SPs - they're less inviting to do useless calculations with them.
  • 0
    5y
    Scrum is a gamification of the process of software delivery. Phases, actions, board, victory points - geek paradise.

    It requires that all sides play the game or at least pretend to be bound by the rules. Unfortunatelly, often at least one side knows that they don’t have to play the stupid nerdy game, because they have the real power.

    A typical scrum collapses after this:

    You won’t make the logo bigger, because it wasn’t committed to the sprint?! Sure, then I’ll find another team.
  • 0
    5y
    @Codex404 probably not long enough then...I think 2 sprints. But still seems like an awfully long time to devote to learning a system when it took a single Sprint planning for us to adjust to the modified point system.
  • 1
    5y
    @aspenscythe though hours are saying less than points because they (hours) have meaning. Estimates are never correct. The best way to avoid giving incorrect estimates is to not give estimates at all. Then no hope and expectations can be made of it.
  • 0
    5y
    @matste thats when the company should say "okay, have fun with the waterfall ride"
  • 0
    5y
    A thing my project manager told me once when I asked about a good way to setup scrum for my own project (with a small online team of 1) she told me that the best way to employ scrum is to take whatever works for you and bend the rest as you need. Its not viable nor efficient to follow scrum exactly unless its a project that absolutely requires it for some reason. Its best to start with whatever feels right to everyone, and then not be afraid to change it based what people report. If something feels bothersome, get rid of it. If hours work better for you than point, do hours... And so on... Just remind the junior that scrum isn't a perfect system, its just a tool with its own tradeoffs and you should be ready to evolve it around your own needs
  • 0
    5y
    @VaderNT None of our devs is against scrum, but also none of them worked agile before.
    And you are right, story points measure the complexity, but in the end it's also necessary to das how many story points can be achieved in a sprint, so there is a way to recalculate them into a time unit.
    I'm afraid they don't understand that using scrum and beeing agile does not only affect development but also the communication towards our clients...
  • 0
    5y
    I can't imagine that our project manager tells our client "your requested feature has a complexity of 13, usually WE geht 10 points done in one week, but that may change " instead of "we estimated your feature with 7 days". In that case, we can simple keep our time estimation.
    Like @Codex404 said, estimates are never correct, but maybe it's just a question when the shit hits the fan, you can either go to the client when you see that your time budget is nearly depleted and ask how to deal with it, or you can give him his invoice and just say, "yeah, Dev X needed 5 days more for 13 story points"
Related Rants
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment