[Pulp-dev] Roadmap Challenges
ipanova at redhat.com
Tue Apr 10 23:39:16 UTC 2018
W/r to stakeholders needs. We have dedicated people on our team who closely
work with the stakeholders, therefore both of the parties are in agreement
1) what needs to get done
2) by when #1 needs to get done
In my understanding if there are some uncertainties about some work then 1)
it was not prioritized 2) it was not brought to the both parties attention.
I agree with Jeff that with Redmine Story we were successfully being able
to describe, design and plan.
In addition to the sub-tasks for commits tracking we have the associated
What i agree with is what brought up Robin - it is not efficient to put on
the sprint work and then let it be there for months.
Maybe would be a good idea for every work that is groomed to set a deadline
- we can speak in terms of time, sprints, releases, whatever we are
This way, when we promise to commit to something as a team, we make sure
that it gets picked up and worked on, and we do not leave/pospone it be
there for X amount of time because maybe it does not really not look
Software Engineer| Pulp| Red Hat Inc.
"Do not go where the path may lead,
go instead where there is no path and leave a trail."
On Tue, Apr 10, 2018 at 9:40 PM, Jeff Ortel <jortel at redhat.com> wrote:
> From a tooling perspective:
> we have had good success in the past with fully defining and designing a
> feature in a Redmine Story. The story (description) provides a good way to
> capture (and edit) the overall design and (comments) support a discussion
> history. Then, the implementation can be broken down and tracked by
> related sub-tasks which are aligned to sprints and cross core/plugin
> boundaries. The feature is complete when all the implementation tasks are
> On 04/06/2018 02:00 PM, Robin Chan wrote:
> To bring this back to your original question, here are some comments in
> Agree w/#1 - I have observed a few different ways that this problems has
> been solved by developers. The requirement here is "I need a way to
> understand all the work and deliverables associated with a feature." This
> question comes down to how do we track of deliverables. This is I think
> secondary and not as much of a problem as the next question.
> #2 - This is essentially a question of planning deliverables. Your
> descriptions is "how will someone know if a feature is committed to"? I
> think full planning is not necessary for commitment. I believe that "full
> planning" part could go in #1 in terms of tracking status. I think the
> question is actually "how will someone know if a feature is committed to
> and when it is committed by" - addition of a time or time frame.
> In my experience, feature work generally went like this:
> 1. Define feature/problem to be solved.
> 2. Investigate:
> - refine requirements/problem definition
> - do enough design or planning of tasks to come up with estimate of
> 3. Commit to work or not
> 4. execute along list of tasks, refine list as you learn.
> Steps 1-3 is part of roadmap planning (higher level planning) and #3-4 is
> sprint planning.
> I think the problem with using the sprint field as we have used it, is
> that if you add something to a sprint, the Scrum definition would lead
> people to assume that the team is committing to it at the end of a defined
> sprint period. We do not. This major departure from industry standard does
> not serve us well in my opinion. We have kept items on sprints for many
> months and then removed it. Even if we were able to convince folks that our
> definition of sprint was "our next few sprints" of work, we don't have any
> accountability that we are actually keeping our commitment here and the
> folks wanting something on the sprint don't have any idea if something
> added to a sprint will be there in 3 weeks or 12 weeks. I think others in
> software are reasonable in understanding that software deliveries aren't
> going to be there until they are, but I think our immediate focus on what
> is in process (impending delivery/next build) and on some of the larger
> On Thu, Mar 29, 2018 at 3:13 PM, Brian Bouterse <bbouters at redhat.com>
>> I want to start a discussion around how Pulp does roadmap planning and
>> some of our current challenges. This is the pre-discussion part of a future
>> PUP. I want to collaborate on characterizing the problems first before we
>> discuss solutions.
>> # The surface problem statement
>> It very difficult for external stakeholders to answer some simple
>> questions about any given feature:
>> * How would a user use this feature exactly?
>> * Is it completed? If not, how much is left to do?
>> * Which release is this going in?
>> * Has this feature been fully planned and accepted as a committed to
>> piece of work?
>> # deeper problems
>> I believe there are two deeper problems contributing to the problem above.
>> 1. Any given feature is typically spread across multiple Redmine tickets.
>> There may be the first implementation, followup changes, adjustments,
>> bugfixes, reworks, docs followups, etc. This makes it practically hard to
>> have the information necessary to answer the first 3 questions ^.
>> 2. Devs of core or a plugin have no clear way to clearly signal that a
>> feature has been fully planned and is committed to. The 'sprint' field has
>> been used heretofore, but the recent feedback suggests that mechanism may
>> not be the best way to indicate that work has been fully planned and
>> accepted. We need a clear way to answer the last question ^.
>> Do you agree or disagree with these problem statements? Do you have
>> anything to add about the problem statements?
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
> Pulp-dev mailing listPulp-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev