[HN Gopher] "Stories" Don't Tell a Story: Good Sprint Planning U...
___________________________________________________________________
"Stories" Don't Tell a Story: Good Sprint Planning Uses Milestones
Author : kiyanwang
Score : 57 points
Date : 2021-06-05 08:42 UTC (1 days ago)
(HTM) web link (cgroom.medium.com)
(TXT) w3m dump (cgroom.medium.com)
| SeriousM wrote:
| User stories are a very effective and important tool to separate
| features while addressing every level technology involved.
| Milestones are another tool and booth are valid to use. It always
| depends on the size and quality of the team that uses the tools.
| theshrike79 wrote:
| Exactly.
|
| Milestone might be "Support for ABBA-Lifter Model 2 in mapping
| system"
|
| Stories would be something like "As a Lifter owner, I want to
| see where my fleet is located" etc.
|
| After completing all the Stories a Milestone is complete and
| can be released to customers.
| awillen wrote:
| "In too many engineering teams, sprint planning and daily standup
| are centered on the sprint board and backlog. Stories (tasks) are
| the focus of attention; discussions are focused on achieving
| pointing targets, the mechanics of how to achieve a particular
| task, or dependencies and sequencing. The problem is that teams
| lose sight of the forest for the trees. We forget that stories
| are only a crude approximation of the work needed to finish an
| initiative; and more importantly, that the work only matters when
| it has delivered end value."
|
| I disagree with the author on the point of standups - they're not
| big-picture strategic sessions; they're about short-term,
| tactical planning. What work are you going to do today? Are you
| blocked by anything?
|
| That's not to say that the big picture should be forgotten, but
| it's wildly impractical to do an initiative-level review every
| single day.
| sidlls wrote:
| > I disagree with the author on the point of standups - they're
| not big-picture strategic sessions; they're about short-term,
| tactical planning. What work are you going to do today? Are you
| blocked by anything?
|
| This has always been my problem with standups: they feel a bit
| too much like micromanagement.
| tharkun__ wrote:
| This may have been due to how your standup worked. Believe me
| I have seen it too and part of why I want to be a team
| lead/scrum master is to make sure this does not happen to my
| team.
|
| Did your standup feel like a report to the Product Owner? Or
| a report to the Scrum Master? Or a report to Team Lead? Not
| good. Creates the feeling you had.
|
| The standup should create conversation between team members.
| 'Oh you said you are doing X while doing your tasj? That
| won't work for my Y, good thing you mentioned it, let's have
| a quick talk after standup'
|
| As a scrum master if they 'report status to you' you can for
| example not look them in the eyes all the time so that they
| can't fixate on you. There are ways to still show them that
| you are paying attention.
|
| If the PO is asking follow-ups that make it clear he's
| expecting status reports to him you can take him aside and
| talk to him about that. It might come to the point where you
| have to threaten to throw him out of standup if he doesn't
| shut up and then he won't even be able to even listen.
|
| Same goes for team lead depending on whether you have a
| separate scrum master or maybe the team lead has that hat.
| sidlls wrote:
| > The standup should create conversation between team
| members.
|
| A team of even adequate--not great, just adequate--people
| working together will have these conversations
| independently.
|
| > 'Oh you said you are doing X while doing your tasj? That
| won't work for my Y, good thing you mentioned it, let's
| have a quick talk after standup'
|
| There are two different cases where this would apply: when
| someone attempts to do something and finds some blocking
| issue, and when someone attempts to do a task out-of-order
| from a dependency.
|
| The first case rarely occurs in a way that a daily standup
| will efficiently address. Most tasks take longer than a day
| to do--the standup is unlikely a time when this sort of
| issue is most efficiently resolved. Other than junior
| engineers or maybe quick bug fixes I rarely encounter an
| engineer who measures his work by the time between
| standups.
|
| The second case is best resolved by having a proper,
| complete design process--requirements analysis, technical
| design (changes in architecture, code, dependencies, etc.),
| and a team-wide review--and a work tracking tool that
| permits tasks to be ordered (e.g. JIRA's "blocked by"
| label). Work doesn't always fit into that neat of a design
| and execution process, obviously, and it's okay to have an
| occasional, regular meeting (e.g. once a week or every
| other week, maybe slightly more often depending on the
| scope of work the team typically has) to address those
| specific issues as-needed. But those meetings shouldn't be
| permanently scheduled on the calendar--just while a given
| project is in progress.
| theshrike79 wrote:
| > A team of even adequate--not great, just adequate--
| people working together will have these conversations
| independently.
|
| Then the daily standup will be really damn fast. =)
|
| On the other hand the daily is a place where you _know_
| that the other person isn't busy and it's a good time to
| raise any concerns or ask for assistance.
| sidlls wrote:
| If it's going to be "really damn fast" because nobody has
| anything (more) to say, it's pointless (and
| micromanagement, for the managers' benefit only).
|
| And if the person is busy, they should indicate as much.
| People shouldn't have to have a carve-out on their
| calendar for concerns or requests for assistance: that's
| an indication of a dysfunctional team.
| theshrike79 wrote:
| My fastest scrums have went like this (on
| $chat_application): <scrum master> anyone
| have anything new for daily? <dev1> nope, still
| working on $task <dev2> nope <tester1> nope,
| still finishing up testing $task2 <scrum master>
| let's skip it then
| marcosdumay wrote:
| Fast meetings do not exist.
|
| Once the time is allocated, if there's nothing of
| importance to discuss then some low value subject will
| always fill it.
| forgotmypw77 wrote:
| >A team of even adequate--not great, just adequate--
| people working together will have these conversations
| independently.
|
| And nobody else will know about them.
| Terretta wrote:
| > _"If you want to build a ship, don't drum up the men to gather
| wood, divide the work, and give orders. Instead, teach them to
| yearn for the vast and endless sea." -- Antoine de Saint-Exupery_
|
| You know, to yearn for a _milestone_?
|
| > _"Compare that to a narrative that leads with purpose: 'we want
| to do THIS THING, so that's why we think we should do THIS WORK.'
| The message is: 'focus on finishing THIS THING.'"_
|
| A thing, which most milestones are, is not a purpose.
|
| If this had said customer outcome, and that the flavor of
| milestone is that the customer is now empowered to achieve that
| outcome, I'd be on board.
|
| For me, this essay fails to connect the aspirational quotes or
| customer purpose with focusing an effort.
| didibus wrote:
| Blog posts like that are often too superficial to be useful.
|
| It be best to run through real examples, ok, what are your actual
| milestones about, how did you break them down, what are your
| actual stories, how do you connect the two, etc.
| dec0dedab0de wrote:
| I just want to make nested checklists to keep track of what needs
| to be done. That anyone on the team can easily change, reorder or
| delete without anyone in management knowing or caring how or why
| we chose to put what we put on the checklist.
|
| Management should only care about the results and money. How we
| organize to get any particular thing done, should be no one
| else's concern.
| theshrike79 wrote:
| > Management should only care about the results and money. How
| we organize to get any particular thing done, should be no one
| else's concern.
|
| This is pretty much what scrum is kinda supposed to be when
| implemented properly. (No True Scrumsman Fallacy =P )
|
| "Management" has a prioritised backlog of items, the team
| commits to executing one of the top items in an allotted
| timeframe. During the timeframe "Management" is not allowed to
| influence the work in any way or change the specifications
| midway.
|
| If they do, everything done so far is supposed to be scrapped
| and the timeframe starts from scratch - this clause is there to
| give an actual measurable cost to messing with the team during
| a sprint.
| gumby wrote:
| Agile was developed for consulting projects and in that context
| can be quite powerful. It also offers some insights that can be
| useful for efforts of a longer and more ambitious scale.
|
| But the wholesale adoption of agile techniques and vocabulary has
| been a cargo-culting disaster, imho.
| theshrike79 wrote:
| Scrum is good when done right.
|
| 1) Everyone. I mean _everyone_ in the organisation needs to
| commit to the Scrum model. Sales guys aren't excepted from the
| scrum cycle. If they need a "quick little thing" they put it in
| the backlog and wait. 2) The Scrum model needs to be adapted to
| the organisation, it's not a one size fits all model. Most
| maintenance-style operations don't fit the standard scrum model
| (ongoing CS issues etc), and testing is kinda iffy (do we test
| the sprint result during the sprint or during the next
| sprint?).
| wirrbel wrote:
| I think there may be a chance for success in going FULL
| scrum, but really there are a couple of caveats.
|
| * The appropriate sprint-length must be found, there is a
| lower-bound by how long you need for developing something
| with user-value (i.e. demoable), and upper bound the
| tolerance of your customer (or sales organisation) to wait
| until requested features will be implemented. Most scrum
| teams seem to use 2 week sprints which is typically too short
| unless you are developing simple products like CRUD
| applications potentially. * If we take 1 sprint-length (1 SL)
| as a basic time unit, then you need to realise that a new,
| highest-priority feature will on average take 1.5 SLs to
| delivery if it really is Priority 1. * teams must really be
| 90% self-reliant to do everything needed in the sprint. Once
| you have need to synchronise development across scrum-teams,
| you loose. basically now value delivery can easily take 2-3
| SL OR needs to be carefully planned / aligned for the same
| sprint ahead of time so you get at a lower-boundary of 2-2.5
| SL (> 1.5 SL) for work involving more than one team, easily
| exploding to 3-4 SLs. deve With these considerations, we
| quickly get into longer-ranges of planning, especially if you
| are in a multiple-team kind of situation, that you get easily
| into when you (a) don't have a dev team deploying to the
| cloud (b) are developing more-complex software systems with
| multiple components / services developed by several teams.
|
| The elephant in the room of course is that all of this thais
| not discussed in your Scrum training, because they mostly
| outline a happy-path for this 8 person team
|
| disclaimer: I prefer Kanban-style sprint-less work mode
| overall.
| theshrike79 wrote:
| Yea, syncing work across multiple teams is a pain in the
| ass.
|
| There really aren't any good solutions for that, only bad
| and worse ones...
| splittingTimes wrote:
| Wholeheartedly agree. On our side we are not only multiple
| dev teams working tightly together on the same product (CAD
| application in a highly regulated medical field), but we
| also have a domain experts group, a designer group and the
| POs that need to prepare the high-level user stories and
| behavior of the features pre development. Our teams work
| with 3 week sprints and we found that in order to actually
| start development of a topic we need ~3SL prep time,
| meaning POs write high-level user stories, domain experts
| discuss how the detailed workflow behavior should best be
| like, then the designers come with mockups. Those are
| typically not aligned and need several feedback loops until
| it is settled. Then we devs need to break this down, look
| into the technical side, groom the tickets, write Dev
| stories and estimate them. Then the PO prioritizes the
| tickets and we pick em for the sprint. Then we develop for
| typically 3 sprints, but sometimes longer. After the pure
| development come the feedback loops again with the domain
| experts and the actual stakeholders. This can also take
| 2-3SL easily. So we have
|
| 3SL prep | actual implementation >= 3SL | 3SL feedback
| loops & polish
|
| Post development our deliveries also have to synch with the
| bi-yearly sales windows of our parent company and need
| coordination for marketing, regulatory affairs /
| verification & validation, training & education and the
| sales team.
|
| The real challenge is to somehow interface our agile
| development process within a traditional workflow
| (marketing, T&E, sales needs to know upfront what features
| will be delivered at a given release some month in advance
| so they can plan and prepare their activities and materials
| for a commercially successful software release.
| drewcoo wrote:
| > The problem is that teams lose sight of the forest for the
| trees.
|
| Oh! That's the problem! Silly me. I thought there were multiple
| problems like:
|
| - rampant micromanagement
|
| - non-devs creating stories for the devs
|
| - "stories" not being used to tell stories
|
| But that's what happens when dev tools (agile) are marketed as
| dev management tools (Agile). The problem is that the systems
| meant to get devs closer to customers have been coopted by middle
| men and now they create distance.
| dragonwriter wrote:
| > Stories (tasks) are the focus of attention; [...] We forget
| that stories are only a crude approximation of the work needed to
| finish an initiative; and more importantly, that the work only
| matters when it has delivered end value.
|
| The _fundamental principle_ of story-based work planning is that
| the story is an atomic unit of end value; stories may be groups
| into larger units that represent broader goals or divided into
| smaller tasks for planning convenience, but the defining aspect
| of the story is that it is the smallest unit of work providing
| independent end-value.
|
| It's true that, especially with Scrum and similar processes with
| timeboxed work cycles, teams tend to end up using "stories" that
| aren't real user stories, but units of work (which may not even
| have started as real user stories, as instead of reserving a
| timeslice for support [refactoring, general infrastructure, and
| other useful for velocity but not directly targeting specific
| user needs tasks] work, the same disfunction leads teams to
| arbitrarily declare that all work must be _called_ stories
| whether or not it is) arbitrarily carved up to fit the cycle
| timebox and the team's [or some decision-maker's] arbitrary
| preference for the number of work items per cycle.
|
| I would argue that this is because sprints are a software
| development process antipattern in and of themselves, are
| particularly in tension with user-story-based work organization,
| and lower the resistance to a number of other antipatterns of the
| general description of applying classic top-down non-agile
| project management within a framework of "agile" buzzwords.
| Spartan-S63 wrote:
| I think this is a result of a lack of granularity in the styles
| of stories. I worked in a heavy XP shop and we were consistent
| in ensuring stories were units of value, chores were things
| that needed to be done to enable the delivery of value, and
| bugs were just that.
|
| Additionally, we didn't point bugs and chores because points
| are supposed to be a measure of delivering value. If you have
| stories as units of work, your points just became yet another
| measure of a unit of work.
|
| Also, having worked in the XP shop and a "traditional Agile"
| shop, we never preplanned sprint work. We worked in one-week
| iterations as a means of bookkeeping, but we never committed to
| work ahead of time. We just pulled off the backlog and kept
| going. Some weeks we'd get more done, some we'd get less, but
| we had a trend line of velocity that gave us a projection of
| how much work we'd get done. I don't actually care much for
| committed-work sprints as a means of getting work done. It just
| doesn't feel useful.
| simonbarker87 wrote:
| In time boxed sprints it annoys me no end that ONLY stories
| get pointed and then a "percentage of the sprint" is reserved
| for unpointed work. Given that points aren't allowed to equal
| time and bugs and chores are allowed to be pointed the
| question becomes "a percentage of what exactly?"
|
| Removing the time bounding makes much more sense as you've
| said above.
|
| I have this argument with my PO and SM - if points don't
| equal time then why do we plot points vs time on a burn down?
|
| Not pointing work in this scenario is just a way for
| management to squeeze extra work in that looks free.
| Spartan-S63 wrote:
| Yep, the conflation of points into time-spent is a
| perversion of Agile and creates an incorrect metric for
| value delivered to the user.
|
| If you look at points as a lagging indicator of time
| estimation, it's much more valuable as you can establish
| trends and look at those trends versus team strength, etc.
| Additionally, if you use the ratio of stories, bugs, and
| chores as a leading indicator of product/team/codebase
| health, you can make intelligent decisions about when
| larger refactors are necessary. If you find yourself
| spending more and more time on bugs, you might want to take
| a step back, assess the cause and invest in fixing it.
|
| Basically, getting rid of timeboxing, establishing team
| SLOs on portion of work (such that breaching your error
| budget requires refactoring/paying down tech debt/halting
| delivery of new value), and ensuring points are only
| assigned to value-producing work, would result in a better
| process and clearer outcomes and impact.
| crucialfelix wrote:
| To me, points should be an estimate of complexity. Higher
| complexity means more unknowns, more traps, larger possible
| range of time to complete. If the current codebase is
| murky, then I add points. I promise that if we fix the
| murky areas in the code then we can build faster and more
| predictably.
|
| A 1 pointer means nothing can really go wrong. It's a
| linear time task.
|
| I don't think the Product Manager digs my philosophical
| approach.
| marcosdumay wrote:
| > We just pulled off the backlog and kept going.
|
| This is called "kanban" in agile-speak, despite it being
| basically the inverse of that term's original meaning from
| production engineering.
|
| And yes, I completely agree that timeboxes are
| counterproductive. It just takes the least reliable part of
| software engineering (task size estimation) uses it as the
| fundamental tool for organization or all activities.
| bitwize wrote:
| > It's true that, especially with Scrum and similar processes
| with timeboxed work cycles, teams tend to end up using
| "stories" that aren't real user stories, but units of work
|
| These are called "enabler stories", and they will be a part of
| any sufficiently large project. The principles of the Agile
| Manifesto, or any other grand pronouncements about the
| relationship between developer and user/customer, are not why
| your company went Agile. Measurability and trackability with
| respect to OKRs is.
| stevenalowe wrote:
| Stories are not tasks. Stories are "placeholders for future
| conversations." [Beck]. Sounds like Scrumfall.
| smitty1e wrote:
| I didn't see much discussion of a Product Owner in TFA.
|
| I don't know the business value and sequencing of any of my "good
| idea faerie" strikes that I put into the backlog.
|
| Grooming the backlog and producing the overall arc of effort
| needs access to more business information than I am privy.
___________________________________________________________________
(page generated 2021-06-06 23:03 UTC)