<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
From a tooling perspective:<br>
<br>
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 complete.<br>
<br>
On 04/06/2018 02:00 PM, Robin Chan wrote:<br>
<blockquote type="cite"
cite="mid:CAAbpX1MXg5h-jRp=WuNTi9T6hVYj3ao6DHp210GQTkpO5T-gSA@mail.gmail.com">
<div dir="ltr">
<div>
<div>
<div>
<div>Brian,<br>
<br>
</div>
To bring this back to your original question, here are
some comments in line.<br>
<br>
</div>
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.<br>
<br>
</div>
#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.<br>
<br>
<div>In my experience, feature work generally went like this:<br>
</div>
<div>1. Define feature/problem to be solved.<br>
</div>
<div>2. Investigate:<br>
- refine requirements/problem definition<br>
</div>
<div> - do enough design or planning of tasks to come up
with estimate of work<br>
</div>
<div>3. Commit to work or not<br>
</div>
<div>4. execute along list of tasks, refine list as you learn.</div>
<br>
</div>
<div>Steps 1-3 is part of roadmap planning (higher level
planning) and #3-4 is sprint planning.<br>
</div>
<div><br>
<br>
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
deliveries.<br>
<br>
</div>
<div>
<div class="gmail_extra">Robin<br>
<br>
</div>
<div class="gmail_extra">
<div class="gmail_quote">On Thu, Mar 29, 2018 at 3:13 PM,
Brian Bouterse <span dir="ltr"><<a
href="mailto:bbouters@redhat.com" target="_blank"
moz-do-not-send="true">bbouters@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>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.<br>
<br>
</div>
<div># The surface problem statement<br>
<br>
It very difficult for external stakeholders to
answer some simple questions about any given
feature:<br>
<br>
</div>
<div>* How would a user use this feature exactly?<br>
</div>
<div>* Is it completed? If not, how much is left to
do?<br>
</div>
<div>* Which release is this going in?<br>
</div>
<div>* Has this feature been fully planned and
accepted as a committed to piece of work?<br>
<br>
</div>
<div># deeper problems<br>
</div>
<div><br>
I believe there are two deeper problems
contributing to the problem above.<br>
<br>
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 ^.<br>
<br>
</div>
<div>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 ^.<br>
</div>
<div><br>
</div>
<div>Do you agree or disagree with these problem
statements? Do you have anything to add about the
problem statements?<br>
<br>
</div>
<div>Thanks!<span class="HOEnZb"><font
color="#888888"><br>
</font></span></div>
<span class="HOEnZb"><font color="#888888">
<div>Brian<br>
</div>
</font></span></div>
</div>
<br>
______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com"
moz-do-not-send="true">Pulp-dev@redhat.com</a><br>
<a
href="https://www.redhat.com/mailman/listinfo/pulp-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Pulp-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev">https://www.redhat.com/mailman/listinfo/pulp-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>