c# adobe pdf reader control : Add page numbers pdf file software control project winforms azure html UWP ScrumAndXpFromTheTrenchesonline07-313-part1823

H
OW WE DO SPRINT PLANNING 
| 21 
one way to wheedle a sprint goal out of the product owner is to literally 
ask that question. 
The goal should be something that has not already been achieved. 
“Impress the CEO” might be a fine goal, but not if he is already impressed 
by the system as it stands now. In that case everybody could go home and 
the sprint goal will still be achieved. 
The sprint goal may seem rather silly and contrived during the sprint 
planning, but it often comes to use in mid-sprint, when people are starting 
to get confused about what they should be doing. If you have several 
Scrum teams (like we do) working on different products it is very useful 
to be able to list the sprint goals of all teams on a single wiki page (or 
whatever) and put them up on a prominent space so that everybody in the 
company (not only top-level management) knows what the company is 
doing – and why! 
Deciding which stories to include in the sprint 
One of the main activities of the sprint planning meeting is to decide 
which stories to include in the sprint. More specifically, which stories 
from the product backlog to copy to the sprint backlog. 
Look at the picture above. Each rectangle represents a story, sorted by 
importance. The most important story is at the top of the list. The size of 
each rectangle represents the size of that story (i.e. time estimate in story 
points). The height of the blue brace represents the team’s estimated 
Add page numbers pdf file - insert pages into PDF file in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Guide C# Users to Insert (Empty) PDF Page or Pages from a Supported File Format
add blank page to pdf; adding pages to a pdf
Add page numbers pdf file - VB.NET PDF Page Insert Library: insert pages into PDF file in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Easy to Use VB.NET APIs to Add a New Blank Page to PDF Document
add pdf pages together; add page number to pdf hyperlink
22 | S
CRUM AND 
XP
FROM THE 
T
RENCHES
velocity, i.e. how many story points the team believes they can complete 
during next sprint.  
The sprint backlog to the right is a snapshot of stories from the product 
backlog. It represents the list of stories that the team will commit to for 
this sprint. 
The team decides how many stories to include in the sprint. Not the 
product owner or anybody else.  
This raises two questions: 
1. How does the team decide which stories to include in the sprint? 
2. How can the product owner affect their decision? 
I’ll start with the second question. 
How can product owner affect which stories 
make it to the sprint? 
Let’s say we have the following situation during a sprint 
planning 
meeting. 
The product owner is disappointed that story D won’t be included in the 
sprint. What are his options during the sprint planning meeting?  
One option is to reprioritize. If he gives item D the highest importance 
level the team will be obliged to add that to the sprint first (in this case 
bumping out story C). 
C# Create PDF Library SDK to convert PDF from other file formats
offer them the ability to count the page numbers of generated creating toolkit, if you need to add some text and draw some graphics on created PDF document file
add a blank page to a pdf; adding page numbers to pdf
C# Word - Word Creating in C#.NET
allow developers to generate standard Word document file but also them the ability to count the page numbers of generated toolkit, if you need to add some text
add pages to pdf document; add page number to pdf file
H
OW WE DO SPRINT PLANNING 
| 23 
The second option is to change the scope – reduce the scope of story A 
until the team believes that story D will fit into the sprint. 
The third option is to split a story. The product owner might decide that 
there are some aspects of story A that really aren’t that important, so he 
splits A into two stories A1 and A2 with different importance levels. 
As you see, although the product owner normally can’t control the 
estimated velocity, there are many ways in which he can influence which 
stories make it into the sprint. 
C# PowerPoint - PowerPoint Creating in C#.NET
developers to generate standard PowerPoint document file but also them the ability to count the page numbers of generated toolkit, if you need to add some text
add page number to pdf in preview; adding page numbers in pdf
C# Word - Word Create or Build in C#.NET
also offer them the ability to count the page numbers of generated using this Word document adding control, you can add some additional Create Word From PDF.
adding a page to a pdf document; add pages to pdf without acrobat
24 | S
CRUM AND 
XP
FROM THE 
T
RENCHES
How does the team decide which stories to 
include in the sprint? 
We use two techniques for this:  
1. 
Gut feel 
2. 
Velocity calculations 
Estimating using gut feel 
Scrum master: “Hey guys, can we finish story A in this sprint?” 
(points to the most important item in the product backlog) 
Lisa: “Duh. Of course we can. We have 3 weeks, and that’s a 
pretty trivial feature.” 
Scrum master: “OK, what if we add story B as well?” (points to 
the second most important item) 
Tom & Lisa in unison: “Still a no-brainer.” 
Scrum master: “OK, what about story A and B and C then?” 
Sam (to product owner): “does story C include advanced error 
handling?” 
Product owner: “no, you can skip that for now, just implement 
basic error handling.” 
Sam: “then C should be fine as well.” 
Scrum master: “OK, what if we add story D?” 
Lisa: “Hmm....” 
Tom: “I think we could do it.” 
Scrum master: “90% confident? 50%?” 
Lisa & Tom: “Pretty much 90%”. 
Scrum master: “OK, D is in then. What if we add story E?” 
Sam: “Maybe.” 
Scrum master: “90%? 50%?” 
Sam: “I’d say closer to 50%”. 
Lisa: “I’m doubtful.” 
Scrum master: “OK, then we leave it out. We’ll commit to A, B, 
C, and D. We will of course finish E if we can, but nobody 
should count on it so we’ll leave it out of the sprint plan. How 
about that?” 
Everybody: “OK!” 
Gut feel works pretty well for small teams and short sprints. 
Estimating using velocity calculations 
This technique involves two steps: 
1. 
Decide estimated velocity 
2. 
Calculate how many stories you can add without exceeding 
estimated velocity 
VB.NET TIFF: VB.NET Sample Codes to Sort TIFF File with .NET
manipulating multi-page TIFF (Tagged Image File), PDF, Microsoft Office If you want to add barcode into a TIFF a multi-page TIFF file with page numbers using VB
add pages to pdf online; add page pdf
C# Excel - Excel Creating in C#.NET
developers to generate standard Excel document file but also them the ability to count the page numbers of generated toolkit, if you need to add some text and
adding page numbers to pdf in preview; add page number pdf file
H
OW WE DO SPRINT PLANNING 
| 25 
Velocity is a measurement of “amount of work done”, where each item is 
weighted in terms of its initial estimate.  
The picture below shows an example of estimated velocity at the 
beginning of a sprint and actual velocity at the end of that sprint. Each 
rectangle is a story, and the number inside is the initial estimate of that 
story. 
Note that the actual velocity is based on the initial estimates of each story. 
Any updates to the story time estimates done during the sprint are 
ignored. 
I can hear your objection already: “How is this useful? A high or low 
velocity may depend on a whole bunch of factors! Dimwitted 
programmers, incorrect initial estimates, scope creep, unplanned 
disturbances during sprint, etc!”  
I agree, it is a crude number. But it is still a useful number, especially 
when compared to nothing at all. It gives you some hard facts. 
“Regardless of the reasons, here is the approximate difference between 
how much we thought we would get done and how much we actually got 
done”. 
What about a story that got almost completed during a sprint? Why don’t 
we get partial points for that in our actual velocity? Well this is to stress 
the fact the Scrum (and in fact agile software development and lean 
manufacturing in general) is all about getting stuff completely, shippably, 
done! The value of stuff half-done is zero (may in fact be negative). Pick 
up Donald Reinertsen’s “Managing the Design Factory” or one of 
Poppendieck’s books for more on that. 
So through what arcane magic do we estimate velocity? 
C# Excel: Create and Draw Linear and 2D Barcodes on Excel Page
can also load document like PDF, TIFF, Word get the first page BasePage page = doc.GetPage REImage barcodeImage = linearBarcode.ToImage(); // add barcode image
add pages to pdf; add page numbers to pdf document in preview
VB.NET Image: Guide to Convert Images to Stream with DocImage SDK
Follow this guiding page to learn how to easily convert a single image or numbers of it an image processing component which can enable developers to add a wide
add a page to a pdf; add pdf pages to word document
26 | S
CRUM AND 
XP
FROM THE 
T
RENCHES
One very simple way to estimate velocity is to look at the team’s history. 
What was their velocity during the past few sprints? Then assume that the 
velocity will be roughly the same next sprint.  
This technique is known as yesterday’s weather. It is only feasible for 
teams that have done a few sprints already (so statistics are available) and 
will do the next sprint in pretty much the same way, with the same team 
size and same working conditions etc. This is of course not always the 
case. 
A more sophisticated variant is to do a simple resource calculation. Let’s 
say we are planning a 3 week sprint (15 work days) with a 4-person team. 
Lisa will be on vacation 2 days. Dave is only 50% available and will be 
on vacation 1 day. Putting all this together... 
…gives us 50 available man-days for this sprint. 
Is that our estimated velocity? No! Because our unit of estimation is story 
points which, in our case, corresponds roughly to “ideal man-days”. An 
ideal man-day is a perfectly effective, undisturbed day, which is rare. 
Furthermore, we have to take into account things such as unplanned work 
being added to the sprint, people being sick, etc.  
So our estimated velocity will certainly be less than 50. But how much 
less? We use the term “focus factor” for this. 
Focus factor is an estimate of how focused the team is. A low focus factor 
may mean that the team expects to have many disturbances or expects 
their own time estimates to be optimistic.   
C#: Use XImage.OCR to Recognize MICR E-13B, OCR-A, OCR-B Fonts
may need to scan and get check characters like numbers and codes. page.RecSettings. LanguagesEnabled.Add(Language.Other); page.RecSettings.OtherLanguage
add pages to pdf file; add or remove pages from pdf
C# Word: How to Use C# Code to Print Word Document for .NET
are also available within C# Word Printer Add-on , like pages at one paper, setting the page copy numbers to be C# Class Code to Print Certain Page(s) of Word.
add page to existing pdf file; add page numbers to pdf files
H
OW WE DO SPRINT PLANNING 
| 27 
The best way to determine a reasonable focus factor is to look at the last 
sprint (or even better, average the last few sprints).       
Actual velocity is the sum of the initial estimates of all stories that were 
completed last sprint.  
Let’s say last sprint completed 18 story points using a 3-person team 
consisting of Tom, Lisa, and Sam working 3 weeks for a total of 45 man-
days. And now we are trying to figure out our estimated velocity for the 
upcoming sprint. To complicate things, a new guy Dave is joining the 
team for that sprint. Taking vacations and stuff into account we have 50 
man-days next sprint. 
So our estimated velocity for the upcoming sprint is 20 story points. That 
means the team should add stories to the sprint until it adds up to 
approximately 20. 
In this case the team may choose the top 4 stories for a total of 19 story 
points, or the top 5 stories for a total of 24 story points. Let’s say they 
28 | S
CRUM AND 
XP
FROM THE 
T
RENCHES
choose 4 stories, since that came closest to 20 story points. When in 
doubt, choose fewer stories. 
Since these 4 stories add up to 19 story points, their final estimated 
velocity for this sprint is 19. 
Yesterday’s weather is a handy technique but use it with a dose of 
common sense. If last sprint was an unusually bad sprint because most of 
the team was sick for a week, then it may be safe to assume that you 
won’t be that unlucky again and you could estimate a higher focus factor 
next sprint. If the team has recently installed a new lightning-fast 
continuous build system you could probably increase focus factor due to 
that as well. If a new person is joining this sprint you need to decrease 
focus factor to take his training into account. Etc. 
Whenever possible, look back several sprints and average out the numbers 
to get more reliable estimates. 
What if the team is completely new so you don’t have any statistics? Look 
at the focus factor of other teams under similar circumstances. 
What if you have no other teams to look at? Guess a focus factor. The 
good news is that your guess will only apply to the first sprint. After that 
you will have statistics and can continuously measure and improve your 
focus factor and estimated velocity. 
The “default” focus factor I use for new teams is usually 70%, since that 
is where most of our other teams have ended up over time. 
Which estimating technique do we use? 
I mentioned several techniques above - gut feeling, velocity calculation 
based on yesterday’s weather, and velocity calculation based on available 
man-days and estimated focus factor.  
So which technique do we use? 
We usually combine all these techniques to a certain degree. Doesn’t 
really take long.  
We look at focus factor and actual velocity from last sprint. We look at 
our total resource availability this sprint and estimate a focus factor. We 
discuss any differences between these two focus factors and make 
adjustments as necessary.  
H
OW WE DO SPRINT PLANNING 
| 29 
Once we have a preliminary list of stories to be included in the sprint I do 
a “gut feeling” check. I ask the team to ignore the numbers for a moment 
and just think about if this feels like a realistic chunk to bite off for a 
sprint. If it feels like too much, we remove a story or two. And vice versa. 
At the end of the day, the goal is simply to decide which stories to include 
in the sprint. Focus factor, resource availability, and estimated velocity 
are just a means to achieve that end. 
Why we use index cards 
Most of sprint planning meeting is spent dealing with stories in the 
product backlog. Estimating them, reprioritizing them, clarifying them, 
breaking them down, etc.  
How do we do this in practice?  
Well, by default, the teams used to fire up the projector, show the Excel-
based backlog, and one guy (typically the product owner or Scrum 
master) would take the keyboard, mumble through each story and invite 
discussion. As the team and product owner discussed priorities and details 
the guy at the keyboard would update the story directly in Excel. 
Sounds good? Well it isn’t. It usually sucks. And what’s worse, the team 
normally doesn’t notice that it sucks until they reach the end of the 
meeting and realize that they still haven’t managed to go through the list 
of stories! 
A solution that works much better is to create index cards and put them up 
on the wall (or a large table).  
This is a superior user interface compared to computer & projector, 
because: 
30 | S
CRUM AND 
XP
FROM THE 
T
RENCHES
! People stand up and walk around => they stay awake and alert 
longer. 
! Everybody feels more personally involved (rather than just the 
guy with the keyboard). 
! Multiple stories can be edited simultaneously. 
! Reprioritizing is trivial – just move the index cards around. 
! After the meeting, the index cards can be carried right off to the 
team room and be used as a wall-based taskboard (see pg 45 
“How we do sprint backlogs”). 
You can either write them by hand or (like we usually do) use a simple 
script to generate printable index cards directly from the product backlog. 
PS – the script is available on my blog at  
http://blog.crisp.se/henrikkniberg. 
Important: After the sprint planning meeting, our Scrum master 
manually updates the Excel-based product backlog with respect to any 
changes that were made to the physical story index cards. Yes, this is a 
slight administrative hassle but we find this perfectly acceptable 
considering how much more efficient the sprint planning meeting is with 
physical index cards.  
One note about the “Importance” field. This is the importance as specified 
in the Excel-based product backlog at the time of printing. Having it on 
the card makes it easy to sort the cards physically by importance 
(normally we place more important items to the left, and less important 
items to the right). However, once the cards are up on the wall you can 
ignore the importance rating and instead use the physical ordering on the 
wall to indicate relative importance ratings. If the product owner swaps 
two items don’t waste time updating the importance rating on the paper. 
Documents you may be interested
Documents you may be interested