Not logged in. · Lost password · Register

Page:  previous  1  2  3  next 
Lara Powollik
Member since May 2014
4 posts
In reply to post ID 132243
Subject: amount of story points in sprint planning
We have a question based on the feedback to our planning document, that Ann asked us to post here:

How are we supposed to deal with overly ambitious sprint planning? Is it the responsibility of the POs to step in when we feel developers are taking on too many features for a week? We would not want to influence developers' grades by not allowing them to code the amount of features they would like to do. But it is us, the POs, who get (negative) feedback, when planning is too ambitious.

Thanks,
Lara
Dirk Riehle
Avatar
Member since Sep 2009
297 posts
How are we supposed to deal with overly ambitious sprint planning? Is it the responsibility of the POs to step in when we feel developers are taking on too many features for a week? We would not want to influence developers' grades by not allowing them to code the amount of features they would like to do. But it is us, the POs, who get (negative) feedback, when planning is too ambitious.

I think the first question is: Is it overly ambitiuous? As a PO, you can tell the developers that this seems overly ambitious to you and they can disagree or agree and you can have a discussion then. Obviously, wild swings in story points taken on suggest an overly ambitiuous sprint.

We value consistency over one-time efforts. You can argue that for some reason you have more time to spend but we really would like you to put in consistent hourse. So, we wonder what is going on when we see wild swings in story points and no consistent development speed.

In terms of grading, we consider the whole team, both POs and SDs on this issue.
http://osr.cs.fau.de
Ann Barcomb
Member since Apr 2014
37 posts
Adding to what Prof. Riehle said, the focus of this class is the process.  Everyone in a team is responsible for the process.  It's important for the team to have a relatively consistent velocity because this enables planning and reduces burn-out.  In the beginning there are often more fluctuations as the team settles into its pattern, but as the term progresses the sprints should end up being fairly uniform in scope.  When I see an ambitious sprint, two thoughts come to mind.  First, the team might not be following the process, and might be trying to put in extra work now.  Second, the planning poker may have failed, and developers might not actually believe that the commitments they've taken on are accurate.  The team should reflect on why the SDs want to commit to more work.  Sometimes it is easy as a software developer to underestimate the amount of work involved.

Of course we are happy when the SDs are enthusiastic and want to complete more work.  A previous term we saw a very interesting impediment, along the lines of "The SDs were too motivated and took some extra tasks from the top of the Product Backlog."  Of course this should not happen like this--the POs should be aware if the SDs want to take on more tasks--but it does show one possible way of dealing with optimism: taking a more conservative number of points and then, if the tasks are completed quickly, approaching other SDs to see if help is required or approaching the POs for additional stories.  This is also how we would expect an SD to respond if the work was vastly underestimated and was finished too quickly.
ferdi0807
Member since Nov 2013
51 posts
Quick question on the final release plan:

Do we need to adapt the final release plan every week if something changes during a sprint (i.e. some features are not implemented or new features are added?)

Thanks Ferdi! :-)
Ann Barcomb
Member since Apr 2014
37 posts
Quote by ferdi0807:
Quick question on the final release plan:

Do we need to adapt the final release plan every week if something changes during a sprint (i.e. some features are not implemented or new features are added?)

Thanks Ferdi! :-)

Yes, you should update the release plan both to reflect what actually happened in completed sprints but also to incorporate any new information which helps with planning future sprints.
Ann Barcomb
Member since Apr 2014
37 posts
Subject: How to account for stories which end up spanning multiple sprints
There has been some confusion on how to account for a task which is worked on over multiple sprints.  The important points to remember are that you want to both know when the story met the definition of done, but you also want to be able to accurately observe the team's velocity over time.  In addition you want to observe the accuracy of your estimates so that you can improve them in the future.

In the following example, task 76 is worked on over two sprints (other tasks are not included for the sake of simplicity).  It was originally estimated at 3 points and in the earlier sprint, 4 were completed.  It was then re-estimated as a total of 5 (1 more to be done).  In the end the size was 8.

This shows how the release plan was changed to reflect new information.

At the start of sprint 9:

Sprint #        User Stories            Estimated Size        Real Size
9                  76                           3
10                102                         1


At the start of sprint 10:

Sprint #        User Stories            Estimated Size        Real Size
9                  76 (4)                      3                            4
10                76 (1)                      1


At the start of sprint 11:

Sprint #        User Stories            Estimated Size        Real Size
9                  76 (4)                      3                            4
10                76 (4)                      1                            4


In the Feature Archive the task is attributed to the sprint when it is done (using the specific meaning of 'done').  Here I've chosen to reflect both estimates which were made, both the original and the planning which was done as part of sprint 10, in order to learn from mistakes in estimating.

#                   Release               Sprint                  Estimated Size           Real Size
76                 2                         10                        3 (+2)                        8
Lara Powollik
Member since May 2014
4 posts
In reply to post ID 132243
Dear all,

some of us were wondering about the final release deliverables as described in slide deck 01A page 21. Could you give us some further details about the quality criteria of each of these deliverables?

Thanks,
Larissa
Ann Barcomb
Member since Apr 2014
37 posts
Quote by Lara Powollik:
Dear all,

some of us were wondering about the final release deliverables as described in slide deck 01A page 21. Could you give us some further details about the quality criteria of each of these deliverables?

Thanks,
Larissa

Were there any artifacts or aspects of the product in particular that you wanted to know about?  From my weekly feedback of the planning documents I expect that there is already a fairly good understanding of the planning artifacts.  User documentation should show a non-technical user how to use the software.  You've probably encountered both good and bad guides online, so think of guides you've liked, which were clearly structured.

As for the final software product, the working criteria should be obvious: a fresh installation of the software should work (perhaps with minimal configuration), there should not be unexplained crashes or broken pages.  The technical documentation should cover both installation (including information on configuration, dependencies, hardware requirements) of the product and an overview of the architecture which would allow someone to develop the product further.  The code repository should not have a clearly organized directory structure and not contain files which are not meant to be checked in.
David24
Member since Oct 2011
60 posts
The code repository should not have a clearly organized directory structure and not contain files which are not meant to be checked in.
Interesting ;-)
This post was edited on 2014-06-26, 20:30 by David24.
Tobias Unger
Member since May 2014
7 posts
In reply to post #23
Quote by Ann Barcomb:
User documentation should show a non-technical user how to use the software.  You've probably encountered both good and bad guides online, so think of guides you've liked, which were clearly structured.

Indeed we've seen different types of documentation. Among all we saw (especially when it comes to documentation for non-technical target groups), video tutorials have been the most useful ones. Obviously one can also link text with screenshots in a "classical" document, however usually the most appealing explanation is a personal demonstration and a demo video is what comes closest to that. Besides, we believe that a written documentation for an App is not very usual.

Are we required to deliver a text-based documentation or are we free to provide a video if we believe it adds more value to our delivered release?
Ann Barcomb
Member since Apr 2014
37 posts
In reply to post #24
Quote by David24:
The code repository should not have a clearly organized directory structure and not contain files which are not meant to be checked in.
Interesting ;-)

Oops! 

Obviously, you should have a clearly organized directory structure.
Ann Barcomb
Member since Apr 2014
37 posts
In reply to post #25
Quote by Tobias Unger:
Indeed we've seen different types of documentation. Among all we saw (especially when it comes to documentation for non-technical target groups), video tutorials have been the most useful ones. Obviously one can also link text with screenshots in a "classical" document, however usually the most appealing explanation is a personal demonstration and a demo video is what comes closest to that. Besides, we believe that a written documentation for an App is not very usual.

Are we required to deliver a text-based documentation or are we free to provide a video if we believe it adds more value to our delivered release?

I think it is best if Dirk answers this.  In my opinion, video can be a great supplement, but does not replace written documentation.  This is because video can only really be accessed sequentially, which makes it great for an overview, but frustrating if you know the basics and are looking for help on a specific topic.  In written documentation, even if it isn't grouped by topic, I can search for a specific term and jump to the relevant text.
This post was edited on 2014-06-27, 11:33 by Ann Barcomb.
ferdi0807
Member since Nov 2013
51 posts
Is the deadline for the documentation also Thursday night? If so, do we have to upload them on github as well?
Ann Barcomb
Member since Apr 2014
37 posts
Quote by ferdi0807:
Is the deadline for the documentation also Thursday night? If so, do we have to upload them on github as well?

You should try to have everything in place before the demo, but certainly it should all be done by Thursday night.  Documentation which helps someone understand the project should be part of the repository.  The exception would be if you produce specific documentation for the industry partner which contains proprietary information that you cannot make public.  But since the software is open source, in general you should make it possible for someone to pick it up and start using it even after you finish the class.
Ann Barcomb
Member since Apr 2014
37 posts
Subject: Final release tag
Today I was asked about tagging of the final release.  What you presented today should already bear the sprint_xx_release_candidate tag.  For the final release, as with the midterm release, the usual sprint_xx_release tag is replaced with the final release tag (as found in the slides and the weekly checklist): product_release_v2.  This is a non-optional release.
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Page:  previous  1  2  3  next 
Go to forum
Datenschutz | Kontakt
Powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2011 by Yves Goergen