<div dir="ltr"><div>I agree with Ina regarding some form of deadline to keep issues from falling by the wayside. I know we're not *really* doing Agile, but both Kanban and Scrum have points or "pull from the top of the stack" features to ensure that less appealing issues are not passed up repeatedly. I see it kind of like our "priority" dropdown but instead of "High, Medium, Low" it's more like "age" with "Needs attention, Average, Newly Added" or something. Not sure how best to track that. Perhaps when doing a sprint review, anything that carries over to the next sprint gets moved up a level in this way, even if only in the description if there's no useful dropdown available in Redmine. Maybe there's a time like with grooming/triage, where midsprint we re-assess tickets we've committed to?<br><br></div><div>We do a good job of prioritizing severity, but I saw someone on IRC mention recently that they wondered how to get attention brought to a less severe issue that just lingers over time. This might be a way to improve our backlog handling.<br></div><div><br></div>--Dana<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>
<p style="font-weight:bold;margin:0;padding:0;font-size:14px;text-transform:uppercase;margin-bottom:0"><span>Dana</span> <span>Walker</span></p>
<p style="font-weight:normal;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span>Associate Software Engineer</span><span style="font-weight:normal;color:#aaa;margin:0"></span></p>
<p style="font-weight:normal;margin:0;font-size:10px;color:#999"><a style="color:#0088ce;font-size:10px;margin:0;text-decoration:none;font-family:'overpass',sans-serif" href="https://www.redhat.com" target="_blank">Red Hat <span><br><br></span></a></p>
<table border="0"><tbody><tr><td width="100px"><a href="https://red.ht/sig" target="_blank"> <img src="https://www.redhat.com/files/brand/email/sig-redhat.png" width="90" height="auto"></a> </td>
</tr></tbody></table>
</div></div></div></div>
<br><div class="gmail_quote">On Tue, Apr 10, 2018 at 7:39 PM, Ina Panova <span dir="ltr"><<a href="mailto:ipanova@redhat.com" target="_blank">ipanova@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><div><div><div><div><div><div>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 on:<br><br></div>1) what needs to get done<br></div>2) by when #1 needs to get done<br><br></div>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.<br><br></div>I agree with Jeff that with Redmine Story we were successfully being able to describe, design and plan.<br></div>In addition to the sub-tasks for commits tracking we have the associated revisions.<br><br></div>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.<br></div>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 comfortable with.<br></div><div>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 appealing.<br></div><div><div><div><div><div><div><div> <br></div></div></div></div></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="m_-2280070212348622109gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br><br>--------<br>Regards,<br><br>Ina Panova<br>Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Tue, Apr 10, 2018 at 9:40 PM, Jeff Ortel <span dir="ltr"><<a href="mailto:jortel@redhat.com" target="_blank">jortel@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 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.<div><div class="m_-2280070212348622109h5"><br>
<br>
On 04/06/2018 02:00 PM, Robin Chan wrote:<br>
<blockquote type="cite">
<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">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="m_-2280070212348622109m_5401973295766612558HOEnZb"><font color="#888888"><br>
</font></span></div>
<span class="m_-2280070212348622109m_5401973295766612558HOEnZb"><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" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
<fieldset class="m_-2280070212348622109m_5401973295766612558mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
Pulp-dev mailing list
<a class="m_-2280070212348622109m_5401973295766612558moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>
<a class="m_-2280070212348622109m_5401973295766612558moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>